Für einen individuellen Ausdruck passen Sie bitte die Einstellungen in der Druckvorschau Ihres Browsers an. Regelwerk

Initiale kommunikative Anbindung und Zertifikatsverwaltung

Dieser Implementierungshinweis ¹ soll die in den Zertifizierungsverfahren identifizierten Fragen zur initialen kommunikativen Anbindung des CLS-Kommunikationsadapters (CLS-KA) durch Klarstellungen beantworten. Die [ TR-03109-5] lässt dem Implementierer des CLS-Ka Freiheiten in der Umsetzung der initialen kommunikativen Anbindung an das SMGW, die dann in ICS konkretisiert werden. Darüber hinaus wurde in Zertifizierungsverfahren festgestellt, dass einige der in der [ TR-03109-5] verwendeten Begriffe im Kontext der Leser unterschiedlich interpretiert wurden.

Dabei liegt der Fokus auf der Inbetriebnahme des CLS-Ka an einem SMGW gemäß [ TR-03109-1v1.1] als auch gemäß [ TR-03109-1v2.0], so dass eine Überführung der kommunikativen Anbindung von einem SMGW mit Zertifikaten gemäß [ TR-03109-1v1.1] zu einem SMGW mit Zertifikaten gemäß [ TR-03109-1v2.0] getestet wurde.

1 Bedeutung der verwendeten Begriffe

• Initiale kommunikative Anbindung (auch Pairing): Dieser in Abschnitt 4.4.2 der [ TR-03109-5] genannte Begriff wird informativ verwendet. Er bezeichnet die Phase in der ein Verbindungsaufbau mit TLS-Handshake zwischen CLS-Ka und SMGW erstmalig durchgeführt wird. Beide Begriffe "initiale kommunikative Anbindung" und "Pairing" werden nicht in Anforderungen verwendet und sind daher nicht bei der Implementierung durch die [ TR-03109-5] vorgeschrieben. Für die initiale kommunikative Anbindung kann der Import vonVertrauensankern oder einZertifikatspinning verwendet werden.

  Ist bei der initialen kommunikativen Anbindung kein Vertrauensanker und kein gepinntes Zertifikat im CLS-Ka konfiguriert, wird die Authentizität des Kommunikationspartners (SMGW) durch organisatorische Maßnahmen vor Ort gewährleistet und der Mechanismus desZertifikatspinning verwendet ("Trust on first use").

  Ist bei der initialen kommunikativen Anbindung bereits ein SM-PKI-Vertrauensanker konfiguriert, wird die Authentizität des SMGW durch die Registrierungs- und Zertifizierungsprozesse der [ SM-PKI-CP] gewährleistet. Stellt dies den Defaultzustand des CLS-Ka dar, erfolgte die initiale kommunikative Anbindung bereits in der Fertigung durch Einspielen des Vertrauensankers.

• Defaultzustand und Auslieferungszustand: In diesem Implementierungshinweis wird der BegriffDefaultzustand für den definierten initialen Zustand des Zertifikatsspeichers (z.B. nach FA.DeactivateTrustAnchor) verwendet. Der Zustand nach FA.RestoreDefaults (Auslieferungszustand) definiert weitere Informationen, die in diesem Implementierungshinweis nicht verwendet werden.
• Pinning: Der Begriff wurde in der [ TR-03109-5] auf unterschiedliche Art verwendet. Er wird daher hier weiter differenziert inPinningzustand undZertifikatspinning.
• Zertifikatspinning: beschreibt die Funktionalität ein SMGW-TLS-Endnutzerzertifikat im CLS-Ka über einen Neustart des CLS-Ka hinaus zu "pinnen".

  Gemäß der Festlegung in [ REQ.FA.PinSmgwCertificate.30] der [ TR-03109-5] kommen nach Durchführung des Zertifikatspinnings TLS-Verbindungenausschließlich unter Verwendung des gepinnten Zertifikats zustande (Direct Trust). Dies gilt unabhängig davon, welche weiteren Vertrauensanker im CLS-Ka hinterlegt sind.

  Es kann gleichzeitig immer nur ein gepinntes Zertifikat im CLS-Ka vorliegen. Einzige Ausnahme davon ist der in [ REQ.FA.PinSmgwCertificate.30] festgelegte "Überlappungszeitraum".

• Pinningzustand: Der Pinningzustand wird durch Auslösen von FA.PinSmgwCertificate aktiviert. Sobald der Zustand aktiv ist, ist das weitere Vorgehen abhängig davon, welcherZertifikatstyp im nächsten erfolgreichen TLS-Handshake präsentiert wurde:
  • Bei CT_Selfsigned: das selbstsignierte Endnutzerzertifikat wird als Vertrauensanker importiert und perZertifikatspinning gepinnt.
  • Bei CT_SMPKI_Signed: das SM-PKI basierte Endnutzerzertifikat wird perZertifikatspinning gepinnt. Ein Import als Vertrauensanker findet nicht statt (vgl. dazu BegriffVertrauensanker).

  Der CLS-Ka validiert bei Durchführung eines Zertifikatspinnings und in nachfolgenden TLS-Handshakes nicht die zeitliche Gültigkeit, den Aussteller und die ExtendedKeyUsage des gepinnten Endnutzerzertifikats.

  Es gilt die Annahme, dass der Pinningzustand nur dann besteht, wenn die Vertrauenswürdigkeit des Kommunikationspartners des CLS-Ka durch den Betreiber organisatorisch gewährleistet wird (z.B. durch einen vertrauenswürdigen Monteur)

• TLS-Handshake: Die zwischen TLS-Client und TLS-Server ausgetauschten Handshake (HS) Nachrichten von "client_hello" bis "finished" (Siehe Ablaufdiagramme in [ [TR-03109-5-DS], Kapitel "TLS"]).
• TLS-Verbindungsaufbau: Die ausgetauschten Nachrichten von der Initiierung der TCP-Verbindung bis zum "finished" desTLS-Handshakes.
• Validierung von Zertifikaten: Prüfung der Zertifikatssignatur mit dem öffentlichen Schlüssel des Ausstellerzertifikates oder Binärvergleich (für gepinnte und administrativ konfigurierte Endnutzerzertifikate)
• Vertrauensanker:Das letzte validierte Zertifikat für die Zertifikatskettenvalidierung. Ein Vertrauensanker ist in der Regel von einer Ca signiert. Selbstsignierte TLS-Endnutzerzertifikate gelten gemäß [ RFC5280] ebenfalls als von einer Ca signiert. Ein Vertrauensanker ist im CLS-Ka im Speicher für Vertrauensanker persistiert.

  Beispiele:

  • SM-PKI-RootCA-Zertifikat, SM-PKI-SubCA-Zertifikat: In diesen beiden Fällen wird einem beliebigen (zertifizierten) SMGW-Endnutzerzertifikat vertraut.
  • Selbstsigniertes SMGW-Endnutzerzertifikat: In diesem Fall wird einem geräteindividuellen SMGW-Endnutzerzertifikat vertraut.

  Ein von der SM-PKI ausgestelltes SMGW-TLS-Endnutzerzertifikat (Typ CT_SMPKI_Signed) stelltkeinen Vertrauensanker