You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optional sollte das Passwort erst sein, wenn dies durch alle Fachdienste unterstützt wird.
(!) Grundsätzlich bietet diese Änderung keinen Mehrwert und kann zu IOP-Problemen führen, da die Account Manager Stand heute ein Passwort bei createCert erwarten.
Die Angabe eines Passworts für den PKCS#12 keystore führt bisher zu keinem Problem und sorgt, zusätzlich dafür, dass der keystore passwort-geschützt übertragen wird, auch wenn der sicherheits-technische Mehrwert dessen gering ist.
So muss ggf. in Clientmodulen, welche diesen geeignet verschlüsselten keystore in der Form weiterverwenden möchten, nach dem Abruf nicht erneut ein entsprechend passwort-geschützter keystore erzeugt werden, sodass der abgerufene keystore unverändert weiterverwendet werden könnte.
Es besteht keine Notwendigkeit dieser Änderung, da die Angabe eines Passwortes aktuell kein Hindernis ist. Dies ist in Relation zu ggf. entstehenden IOP-Problemen zu betrachten.
(Beachte: damalige Diskussion drehte sicher vielmehr um die encryption des keystores selbst nicht um das Passwort.)
Relevante Afo. FD-Spec:
A_18784-04 - Bereitstellung Schlüssel und Zertifikat für Clientmodul als passwortgeschützte PKCS#12 Datei
The text was updated successfully, but these errors were encountered:
Ich sehe hier keine IOP Probleme, sofernClientmodule die Version des Fachdienstes berücksichtigt. Die AFO ist abwärtskompatibel und reduziert für künftige CM die Komplexität.
Für die Version des Fachdienst wäre es sinnvoll diese in der ServiceInformation aufgenommen werden würde. Die Unterscheidung der Fachdienstversion muss ohnehin aufgrund neuer Schnittstellen stattfinden.
Korrekt, das Passwort darf erst ab KIM 1.5.3 Fachdienste optional sein.
Vorschlag: in "ServiceInformation.yaml" wird die Version des Fachdienstes aufgenommen.
Scope:
AccountManager.yaml
gemSpec_CM_KOM-LE:
Optional sollte das Passwort erst sein, wenn dies durch alle Fachdienste unterstützt wird.
(!) Grundsätzlich bietet diese Änderung keinen Mehrwert und kann zu IOP-Problemen führen, da die Account Manager Stand heute ein Passwort bei createCert erwarten.
Die Angabe eines Passworts für den PKCS#12 keystore führt bisher zu keinem Problem und sorgt, zusätzlich dafür, dass der keystore passwort-geschützt übertragen wird, auch wenn der sicherheits-technische Mehrwert dessen gering ist.
So muss ggf. in Clientmodulen, welche diesen geeignet verschlüsselten keystore in der Form weiterverwenden möchten, nach dem Abruf nicht erneut ein entsprechend passwort-geschützter keystore erzeugt werden, sodass der abgerufene keystore unverändert weiterverwendet werden könnte.
Es besteht keine Notwendigkeit dieser Änderung, da die Angabe eines Passwortes aktuell kein Hindernis ist. Dies ist in Relation zu ggf. entstehenden IOP-Problemen zu betrachten.
(Beachte: damalige Diskussion drehte sicher vielmehr um die encryption des keystores selbst nicht um das Passwort.)
Relevante Afo. FD-Spec:
A_18784-04 - Bereitstellung Schlüssel und Zertifikat für Clientmodul als passwortgeschützte PKCS#12 Datei
The text was updated successfully, but these errors were encountered: