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 von Vertrauensankern oder ein Zertifikatspinning 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 des Zertifikatspinning 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 Begriff Defaultzustand 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 in Pinningzustand und Zertifikatspinning.
• 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-Verbindungen ausschließ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, welcher Zertifikatstyp im nächsten erfolgreichen TLS-Handshake präsentiert wurde:
  • Bei CT_Selfsigned: das selbstsignierte Endnutzerzertifikat wird als Vertrauensanker importiert und per Zertifikatspinning gepinnt.
  • Bei CT_SMPKI_Signed: das SM-PKI basierte Endnutzerzertifikat wird per Zertifikatspinning gepinnt. Ein Import als Vertrauensanker findet nicht statt (vgl. dazu Begriff Vertrauensanker).

  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" des TLS-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) stellt keinen Vertrauensanker dar, da die oben genannte Zertifikatskettenvalidierung damit nicht möglich ist.

  Der Speicher für Vertrauensanker kann nach Zertifikatstyp in der Implementierung differenziert sein. Diese Differenzierung bleibt an den Schnittstellen des CLS-KA verborgen.

• Pairing Mode: (nach Abschnitt 3.2.1.3 der [TR-03109-5]): Hier sind mit "DT und "PKI" keine diskjunkten Zustände oder Betriebsarten des CLS-KA gemeint sondern die Art des für die TLS-Verbindung gewählten Vertrauensmodells.
• Wirkbetrieb:ein Zustand des CLS-KA in dem die vollständige Funktionalität zur Verfügung steht. Dieser Zustand wird nach Abschluss der initialen kommunikativen Anbindungerreicht. Es ist für die Implementierung dringend empfohlen die Funktionalität vor Erreichen des Wirkbetriebs auf diejenige Funktionalität einzuschränken, die für die Erreichung des Wirkbetriebs notwendig ist.
• Zertifikatstyp: Art eines Zertifikats basierend auf verschiedenen Eigenschaften wie Aussteller und Nutzbarkeit als Certificate Authority (CA). Siehe Tabelle 1 für eine Übersicht der relevanten Zertifikatstypen.

Tabelle 1 Übersicht der Zertifikatstypen

2 Getestete Zustandsübergänge des CLS-KA für die Mindestinteroperabilität

Die nachfolgenden Zustandsdiagramme stellen die Zustände und Zustandsübergänge dar, die im Rahmen der initialen kommunikativen Anbindung in Abhängigkeit vom Defaultzustand relevant sind. Weitere Details sind den nachfolgenden Kapitel zu entnehmen.

Die Zustandsdiagramme sind nicht als Einschränkung möglicher Lösungen zu verstehen sondern stellen die im Rahmen des [TR-03109-5] Verfahrens überprüften Abläufe dar. Weitere (herstellerspezifische) Zustände oder Zustandsübergänge sind zulässig, werden im [TR-03109-5] Verfahren aber nicht getestet.

Die Festlegung einer solchen Mindestinteroperabilität ist notwendig, um eine automatisierte Testbarkeit sicherzustellen. Desweiteren wird dadurch ein einheitlicher Prozess für die initiale kommunikative Anbindung für CLS-KA aller Hersteller festgelegt. Zusätzliche herstellerspezifische Prozesse werden durch diese Festlegung nicht ausgeschlossen. Um einen Migrationspfad beim Wechsel von selbstsignierten zu SM-PKI basierten Endnutzerzertifikaten auf SMGW Seite zu ermöglichen, wird dieser Weg ebenfalls im Zustandsdiagramm vorgesehen.

Die zwei Zustandsdiagramme gehen von unterschiedlichen Defaultzuständen und damit Startzuständen aus:

• Defaultzustand "Leer" (Abbildung 1): hierbei wird der CLS-KA ohne voreingespielte Vertrauensanker oder gepinnte Zertifikate ausgeliefert und es ist eine initiale kommunikative Anbindung notwendig, um den Wirkbetrieb zu erreichen. Sobald der CLS-KA gestartet wird, geht er sofort in den Pinningzustand über.
• Defaultzustand "PKI Trust" (Abbildung 2): hierbei wird der CLS-KA mit voreingespielten SM-PKI CA-Zertifikaten als Vertrauensanker ausgeliefert. Der CLS-KA befindet sich nach dem Start sofort im Wirkbetrieb.

Beide Zustände sind vom jeweils anderen Defaultzustand erreichbar durch Aufruf von FA.PinSmgwCertificate, FA.ImportSmgwTrustAnchor und FA.DeactiveSmgwTrustAnchor.

Für einen CLS-KA mit Defaultzustand "PKI Trust" ist es dringend empfohlen in der Betriebsführung zu vermeiden alle Vertrauensanker zu entfernen, da dies eine Schwächung des Sicherheitsniveau darstellt. Für eine erneute initiale kommunikative Anbindung ist sonst vom Betreiber sicherzustellen, dass "[...] gewährleistet ist, dass das TLS-Zertifikat des SMGW unverändert zum CLS-Kommunikationsadapter übermittelt wird." (gemäß Abschnitt 4.4.2 von [TR-03109-5]).

Abbildung 1. Zustandsübergänge bei Defaultzustand "Leer"

Abbildung 2. Zustandsübergänge bei Defaultzustand "PKI Trust"

3 Klarstellungen

Konzeptioneller und prozessualer Kontext

• Solange an der Messstelle des CLS-KA kein SMGW installiert ist, das SM-PKI-Zertifikate im HAN präsentiert, bleibt dem CLS-KA nur die Möglichkeit den Pairing Mode DT (mit Zertifikatspinning) für die initiale kommunikative Anbindung zu verwenden. Dennoch wird vorausgesetzt, dass der CLS-KA künftig vom SMGW präsentierte SM-PKI-Endnutzerzertifikate gegen einen Vertrauensanker validieren kann. Dies wird im Rahmen der [TR-03109-5] Zertifizierung geprüft. Der spätere authentische Import eines SM-PKI-Vertrauensanker (über FA.ImportSmgwTrustAnchor) über das SMGW (Fernkonfiguration) setzt somit derzeit ein Zertifikatspinning voraus.
• Die initiale kommunikative Anbindung ohne vorinstallierte Vertrauensanker zur Validierung des SMGW-Zertifikates soll möglich sein (Zustand "Leer"). Dies ergibt sich daraus, dass im Falle von Pairing Mode DT anderenfalls das individuelle SMGW an der Messstelle bekannt sein müsste oder das SMGW ein SM-PKI-Zertifikat präsentieren müsste (was innerhalb eines mehrjährigen Übergangszeitraumes nicht der Fall ist).
• Das Ende der zeitlichen Gültigkeit ("validityPeriod.to") von präsentierten SMGW-Endnutzerzertifikaten (CT_SMPKI_Signed als auch CT_Selfsigned) sollte nicht geprüft werden, um die kommunikative Verfügbarkeit des CLS-KA nicht zu beschränken. Da der GWA unter Berücksichtigung kryptografischer Empfehlungen die kommunikative Anbindung des CLS an das SMGW im Rahmen seiner Verantwortlichkeit überwacht, kann er die Zertifikatswechselprozesse der SMGW- und CLS-KA-Zertifikate zum geeigneten Zeitpunkt koordinieren. Ein Administrator des CLS-KA wird nicht vorausgesetzt.

Interpretation der Anforderungen der TR-03109-5

• FA.PinSmgwCertificate: Das Auslösen des FA bringt den CLS-KA in einen Zustand, in dem das vom SMGW im TLS-Handshake (siehe [TR-03109-5-DS] Kapitel TLS) eines im HKS.TLSPROXY.* präsentierten TLS-Endnutzer-Zertifikates (GW_HAN_TLS_CRT) nicht gegen einen Vertrauensanker validiert wird. Ziel dieses Zustands ist das im TLS-Handshake vom Kommunikationspartner (SMGW) präsentierte Zertifikat für Direct-Trust als Vertrauensanker zu importieren (nur für CT_Selfsigned) und mit diesem Zertifikat ein Zertifikatspinning (Typen CT_Selfsigned oder CT_SMPKI_Signed) vorzunehmen.

  Sofern der CLS-KA TLS-Server ist (HKS.TLSPROXY.SRV) fordert der CLS-KA das TLS-Client-Zertifikat des SMGW im nächsten TLS-Handshake an. Das TLS-Zertifikat wird gemäß [REQ.FA.PinSmgwCertificate.30] nach erfolgreichem Abschluss des TLS-Handshakes als Vertrauensanker importiert, wenn es nach [TR-03109-5-DS] Kapitel "HAN-Zertifikate" als GW_HAN_TLS_CRT (nur Typ CT_Selfsigned) gültig ist.

  Ein Zertifikat "CT_pki" (Typ CT_SMPKI_Signed) kann im Sinne von Direct Trust für ein Zertifikatspinning verwendet aber nicht als Vertrauensanker importiert werden, da es sich nicht um ein selbstsigniertes oder ein CA-Zertifikat handelt. Dieses Vorgehen ist sinnvoll, wenn kein Vertrauensanker im CLS-KA hinterlegt ist und das anzubindende SMGW bereits SM-PKI Endnutzerzertifikate verwendet. Ziel dieses Vorgehens ist die Ermöglichung einer Kommunikation, um zeitnah den zugrundeliegenden Vertrauensanker zu importieren und das Zertifikatspinning wieder aufzulösen (Zielzustand "PKI Trust").

  Sobald ein Zertifikatspinning durchgeführt wurde, wird der Pinningzustand beendet.

  Da in [REQ.FA.PinSmgwCertificate.20] das Zertifikatspinning im Pinningzustand nur bei vom bisher hinterlegten abweichendem SMGW-TLS-Zertifikat durchgeführt wird, haben folgende TLS-Handshakes mit dem bereits gepinnten Zertifikat keine Auswirkung auf den Pinningzustand und die gepinnten Zertifikate.

• Interpretation zur "Ausnahme" bei Sicherung der Kommunikation in [REQ.IOP.KS.HAN.10]: Der Anwendungsdatenaustausch zwischen SMGW und CLS-KA (innerhalb von TLS) setzt eine erfolgreiche Authentifizierung des SMGW voraus. Die Ausnahme betrifft nur das Zertifikatspinning des GW_HAN_TLS-Zertifikates im TLS-Handshake. Nach Durchführung der initialen kommunikativen Anbindung besteht eine Mutual Authentication (Zustände im " Wirkbetrieb").
• FA.DeactivateTrustAnchor: Da dieser FA zur Herstellung eines definierten Zustandes für die initiale kommunikative Anbindung sowohl für die Tests des CLS-KA als auch für den Einsatz an der Messstelle benötigt wird, ist es notwendig alle oder nur einzelne über Aufrufparameter festgelegte Vertrauensanker (CT_Selfsigned oder SM-PKI CA-Zertifikate) oder gepinnte Zertifikate (CT_Selfsigned oder CT_SMPKI_Signed) deaktivieren zu können. Nach dem Deaktivieren aller Vertrauensanker und aller gepinnten Zertifikate ist der Pinningzustand aktiviert. (Siehe FA.PinSmgwCertificate).
• [REQ.FA.ImportSmgwTrustAnchor.10]: Beim Import wird nur die syntaktische und strukturelle Gültigkeit des Zertifikates geprüft. Weitere Validierungen erfolgen bei der Zertifikatsverwendung.

4 Reduktion der Pairing-Varianten

Bis zur Verfügbarkeit von SMGW an der Messstelle, die ein GW_HAN_TLS_CRT aus der SM-PKI präsentieren, wird kein SM-PKI-Vertrauensanker im CLS-KA benötigt. Aus diesem Grunde sollten CLS-KA zunächst unter Verwendung von Zertifikatspinning installiert werden und bei Ausstattung der Messstelle mit einem SMGW nach [TR-03109-1v2.0] der SM-PKI-Vertrauensanker über FA.ImportTrustAnchor via HKS.TLSPRO-XY* installiert werden.

Zur Verbesserung der Interoperabilität und Testbarkeit wird zur Reduktion der Implementierungsvarianten der initialen kommunikativen Anbindung folgendes empfohlen:

• Es sind mindestens zwei Auslöser im [ICS.FA.PinSmgwCertificate.10] anzugeben (Automatisierte Testbarkeit und Migration):
  1. Es liegt kein Vertrauensanker im CLS-KA vor. (Defaultzustand oder durch FA.DeactivateSmgwTrustAnchor verursacht)
  2. Empfang der Anforderungsnachricht für FA.PinSmgwCertificate über HKS.TLSPROXY* (Begründung: Automatisierte Testbarkeit und Fernadministration)
• [ICS.FA.ImportSmgwTrustAnchor.10]: Dieser FA soll nicht automatisch ausgelöst werden. Mindestens ein Auslöser soll eine via HKS.TLSPROXY* empfangene Nachricht sein. (Begründung: Sicherheit und automatisierte Testbarkeit)
• [ICS.FA.ImportSmgwTrustAnchor.20]: Hier muss ein positiver Wert (> 0) gewählt werden. Die Obergrenze sollte wenige Tage nicht überschreiten (Begründung: Sicherheit und automatisierte Testbarkeit)
• [ICS.FA.DeactivateSmgwTrustAnchor.10]: Mindestens ein Ereignis muss der Empfang einer Nachricht über HKS.TLSPROXY* zum Deaktivieren eines Vertrauensankers oder zum Löschen eines gepinnten Zertifikates sein (Automatisierte Testbarkeit, Fernadministration). Sobald kein Vertrauensanker und kein gepinntes Zertifikat mehr im CLS-KA vorliegt, geht der CLS-KA wegen [ICS.FA.PinSmgwCertificate.10] (Nr.1) in den Pinningzustand über.
• FA.ImportSmgwTrustAnchor: Beim erfolgreichen Import des Vertrauensanker-Zertifikates werden gepinnte Zertifikate aus dem Speicher entfernt. Alle Vertrauensanker-Zertifikate bleiben erhalten.

5 Anwendungs- und Implementierungshinweise

TR-03109-5

• [REQ.IOP.KS.HAN.10]: Um die Authentizität und Vertraulichkeit der Daten im TLS-Proxy-Kanal zu gewährleisten, MUSS der CLS-Kommunikationsadapter das SMGW authentifizieren und den TLS-Verbindungsaufbau beenden, sofern das vom Kommunikationspartner im HAN präsentierte TLS-Client Zertifikat[...]

  Korrektur: Das Wort Client wird gestrichen, da die Anforderung zum Beenden des TLS-Verbindungsaufbaues sowohl für präsentierte TLS-Client- als auch TLS-Server-Zertifikate gilt.

• [REQ.IOP.KS.HAN.11]: Sofern im CLS-Kommunikationsadapter keine Vertrauensanker und keine gepinnten Zertifikate hinterlegt sind MUSS der CLS-Kommunikationsadapter den TLS-Verbindungsaufbau akzeptieren, ohne die in REQ.IOP.KS.HAN.10 genannten Prüfungen durchzuführen.

  Korrektur: Die Anforderung wird ergänzt.

  Durch diese Ergänzung wird die in Abschnitt 4.4.2 der [TR-03109-5] genannte "Ausnahme" durch eine normative Anforderung gestützt, um den Pinningzustand zu ermöglichen.

• [REQ.FA.PinSmgwCertificate.20]: Der CLS-Kommunikationsadapter MUSS direkt nach Auslösen des FA für die in ICS.FA.PinSmgwCertificate.30 festgelegte Dauer in einen Zustand gehen (Siehe ICS.FA.PinSmgwCerti-ficate.10), in dem das beim nächstem TLS-Handshake mit dem SMGW präsentierte TLS-Zertifikat vom Typ CT_Selfsigned, das sich von GW_HAN_TLS_CERT_n unterscheidet, als SMGW-Vertrauensanker GW_HAN_T-LS_CRT_n+1 verwendet ("gepinnt") wird.

  Korrektur: der Begriff ("gepinnt") wird gestrichen.

  Zusätzlich erfolgt folgende Ergänzung: "[...] präsentierte TLS-Zertifikat vom Typ CT_Selfsigned, das [...]".

  Die Einschränkung ist notwendig, da ein Zertifikat vom Typ CT_SMPKI_Signed per Definition keinen Vertrauensanker darstellt und die Anforderung sonst widersprüchlich wäre.

• [REQ.FA.PinSmgwCertificate.30]: Der CLS-Kommunikationsadapter MUSS in dem in REQ.FA.PinSmgwCer-tificate.20 genannten Zustand das im nächsten HAN-TLS-Handshake empfangene bisher nicht bekannte TLS-Client- oder Server-Zertifikat, als GW_HAN_TLS_CRT_n+1 persistieren ("Zertifikatspinning") und nach Ende eines Überlappungszeitraumes ausschließlich für die TLS-Authentifizierung des SMGW in folgenden TLS-Handshakes (Siehe Abschnitt 4.4) verwenden.

  Korrektur: es erfolgt folgende informative Ergänzung: "[...] persistieren ("Zertifikatspinning") und nach Ende [...]"

• [REQ.FA.PinSmgwCertificate.40]: Sofern der CLS-Kommunikationsadapter bereits einem SMGW-Vertrauensanker (GW_HAN_TLS_CRT_n vom Typ CT_Selfsigned oder einem SM-PKI-CA-Zertifikat) vertraut, MUSS der CLS-Kommunikationsadapter in einem Überlappungszeitraum gemäß ICS.FA.PinSmgwCertificate.40 im TLS-Handshake sowohl das bisherige als auch durch diesen FA gepinnte GW_HAN_TLS_CRT_n+1 zur Validierung verwenden können.

  Korrektur: es werden die Typen der Zertifikate wie folgt ergänzt " (GW_HAN_TLS_CRT_n vom Typ CT_Selfsigned oder einem SM-PKI-CA-Zertifikat)".

• [REQ.FA.PinSmgwCertificate.41]: Sofern im CLS-Kommunikationsadapter bereits ein Zertfikatspinning vorgenommen wurde für ein Endnutzerzertifikat (GW_HAN_TLS_CRT_n vom Typ CT_Selfsigned oder vom Typ CT_SMPKI_Signed), MUSS der CLS-Kommunikationsadapter in einem Überlappungszeitraum gemäß ICS.FA.PinSmgwCertificate.40 im TLS-Handshake sowohl das bisherige als auch durch diesen FA gepinnte GW_HAN_TLS_CRT_n+1 zur Validierung verwenden können.

  Korrektur: Die Anforderung wird ergänzt.

  Diese Ergänzung ist notwendig, da sich REQ.FA.PinSmgwCertificate.40 nur auf Vertrauensanker bezog und nicht auf Zertifikatspinning.

• [REQ.FA.ImportSmgwTrustAnchor.10]: Der CLS-Kommunikationsadapter MUSS den über die Schnittstelle gemäß ICS.FA.ImportSmgwTrustAnchor.10 empfangenen Vertrauensanker zur Validierung des GW_HAN_T-LS_CRT ablehnen, sofern dessen Syntax nicht den Vorgaben gemäß Detailspezifikation [DS] Kapitel HAN-Zertifikatsprofile Typ ATyp CT_Selfsigned (Direct-Trust) oder einem Root- oder Sub-CA-Zertifikat der SM-PKI gemäß [TR-03109-4] entspricht.

  Korrektur: der Begriff HAN-Zertifikatsprofile Typ A wird ersetzt durch HAN-Zertifikatsprofile Typ CT_Selfsigned.

• [REQ.FA.PinSmgwCertificate.50]: Der CLS-Kommunikationsadapter MUSS den Pinningzustand beenden, sobald im Rahmen der FA-Ausführung ein Zertifikatspinnin g erfolgreich durchgeführt wurde.

  Korrektur: Die Anforderung wird ergänzt.

  Diese Ergänzung ist notwendig, da ansonsten Umsetzungen möglich sind, in denen der Pinningzustand weiterhin erhalten bleibt und ggf. ein nachfolgender TLS-Handshake unerwünschterweise ein Zertifikatspinning für ein anderes Zertifikat durchführt.

• [REQ.FA.DeactivateSmgwTrustAnchor.30]: Der CLS-Kommunikationsadapter MUSS als Aufrufparameter den zu deaktivierenden Vertrauensanker oder das zu entfernende gepinnte Zertifikat akzeptieren.

  Korrektur: Die Anforderung wird ergänzt.

  Diese Ergänzung stellt eine Konkretisierung des in Abschnitt 3.2.7.4 der [TR-03109-5] definierten Implementierungshinweises dar. Eine solche Umsetzung ist bereits jetzt für die Testfalldurchführung über das Herstellertool gefordert und unterlegt somit die bereits bestehenden Umsetzungen mit einer normativen Basis.

• [REQ.FA.DeactivateSmgwTrustAnchor.40]: Der CLS-Kommunikationsadapter MUSS bei Fehlen eines Aufrufparameters alle hinterlegten Vertrauensanker und alle festgelegten Zertifikatspinnings deaktivieren.

  Korrektur: Die Anforderung wird ergänzt.

  Diese Ergänzung stellt eine Vereinfachung für die Betriebsprozesse und die automatisierte Testbarkeit dar, da so keine Kenntnis über die konkret hinterlegten Zertifikate notwendig ist.

• [REQ.FA.ImportSmgwTrustAnchor.40]: Sofern der CLS-Kommunikationsadapter bereits einem SMGW Vertrauensanker (GW_HAN_TLS_CRT_n oder SMPKICAZertifikat) vertraut, MUSS der CLS-Kommunikationsadapter in einem Überlappungszeitraum gemäß ICS.FA.ImportSmgwTrustAnchor.10 im TLS-Handshake sowohl das bisherige als auch das durch diesen FA importierte GW_HAN_TLS_CRT oder CA Zertifikat zur Validierung verwenden können.

  [ICS.FA.ImportSmgwTrustAnchor.20]: Der Hersteller MUSS im ICS deklarieren, wie lang (in Stunden) der CLS-Kommunikationsadapter im Zustand verbleibt, gemäß REQ.FA.ImportSmgwTrustAnchor.40 im HAN-TLS-Handshake mehrere SMGW Vertrauensanker validieren zu können.

  Korrektur: Anforderung und ICS entfallen ersatzlos.

  REQ.FA.ImportSmgwTrustAnchor.20 fordert, dass der CLS-KA mindestens zwei parallele Vertrauensanker unterstützt. Das Deaktivieren eines Vertrauensankers erfolgt über FA.DeactivateSmgwTrustAnchor. Die zeitliche Festlegung eines Überlappungszeitraums ist hierbei nicht sinnvoll, da kein Automatismus zum Deaktivieren durch die [TR-03109-5] vorgegeben wird.

  Detailspezifikation zur TR-03109-5

• [REQ.TA.TLS.Handshake.160] Die Implementierung des TLS Clients MUSS ein empfangenes TLS-Server-Zertifikat vor der Verwendung mit Certificate Path Validation gemäß [RFC5280] bis zu einem administrativ konfigurierten CA-Zertifikat validieren

  Korrektur: des TLS-Clients wird gestrichen, Server- wird gestrichen.

  Die Anforderung bezieht sich nicht nur auf TLS-Clients sondern gleichermaßen auf TLS-Server.

• [REQ.TA.TLS.Handshake.170] Sofern gemäß Kommunikationsszenario die Implementierung des TLS-Clients selbstsignierte TLS-Server-Zertifikate akzeptieren kann, MUSS die Implementierung ein empfangenes, selbstsigniertes Server-Zertifikat[...]

  Korrektur: des TLS-Clients wird gestrichen, Server wird gestrichen (zweimal). Die Anforderung bezieht sich nicht nur auf TLS-Clients sondern gleichermaßen auf TLS-Server.

  Korrektur: selbstsigniert wird gestrichen, da auch von einer CA ausgestellte Endnutzer-Zertifikate für Direct-Trust durch Binärvergleich validiert werden können.

Literaturverzeichnis

[RFC5280] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF, D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley und W. Polk. 2008.

[SM-PKI-CP] SM-PKI-CP - Certificate Policy für die SM-PKI v1.1.1.2017. Bundesamt für Sicherheit in der Informationstechnik.

[TR-03109-1v1.1] Technische Richtlinie TR-03109-1, v.1.1.1: Anforderungen an die Interoperabilität der Kommunikationseinheit eines intelligenten Messsystems. 2021. Bundesamt für Sicherheit in der Informationstechnik.

[TR-03109-1v2.0] Technische Richtlinie TR-03109-1, v2.0: Anforderungen an die Interoperabilität der Kommunikationseinheit eines intelligenten Messsystems.2024. Bundesamt für Sicherheit in der Informationstechnik.

[TR-03109-5] Technische Richtlinie TR-03109-5, v1.0: Kommunikationsadapter. 2023. Bundesamt für Sicherheit in der Informationstechnik.

[TR-03109-5-DS] Detailspezifikation zur TR-03109-5 v1.0: Anforderungen an die Interoperabilität eines CLS-Kommunikationsadapters. 2023. Bundesamt für Sicherheit in der Informationstechnik.

________

1) Implementierungs- und Anwendungshinweise schließen Interpretationslücken in der TR oder geben "best practice"-Hinweise zur Umsetzung bestimmter Dienste oder Details. Es handelt sich um nicht-verbindliche Dokumente, die die Sichtweise bzw. Interpretation des BSI aufzeigen und keinen direkten Einfluss auf die TR haben, auf die sie sich beziehen.

ENDE