C_12257_Anlage_V1.0.0
Prereleases:
C_12257_Anlage
Inhaltsverzeichnis
1 Änderungsbeschreibung
Zur Prüfung und Erstellung qualifizierter Zertifikate gemäß eIDAS-Verordnung wird in Deutschland gemäß Vertrauensdienstegesetz (VDG) die Vertrauensliste der Bundesnetzagentur (BNetzA-VL) verwendet. Die technischen Vorgaben und Rahmenbedingungen für Vertrauenslisten der EU wurden bisher durch den Implementation Act CID 2015/1505 rechtskräftig und verweisen dabei als technische Basis auf den Standard ETSI TS 119 612 in der Version 2.1.1 (von 07/2015). Für Mai 2025 wurde von der EU-Kommission eine Aktualisierung des Implementation Act angekündigt, wodurch als technische Grundlage für die Vertrauenslisten nun die Version 2.3.1 des ETSI-Standards Verwendung finden wird.
Auch die QES-Signaturen und -Zertifikate in der Telematikinfrastruktur (TI) unterliegen diesen technischen Regelungen und müssen verpflichtend eingehalten werden.
Da die Erstellung und Bereitstellung der BNetzA-VL durch die Bundesnetzagentur erfolgt und dabei von der EU-Kommission bereitgestellte Tools verwendet werden, wird nach Inkrafttreten des aktualisierten Implementation Act der aktualisierte Standard ETSI TS 119 612 v.2.3.1 (von 11/2024) bei der nächsten Veröffentlichung der BNetzA-VL sofort zum Einsatz kommen.
Eine Berücksichtigung des neuen Standards ist für alle Produkttypen der TI zwingend notwendig, die QES-Zertifikate prüfen. Ggf. sind dafür Produkt-Anpassungen vorzunehmen.
Die gematik beschreibt in der gemSpec_PKI mit TUC_PKI_036 (GS-A_5484-01), wie QES-prüfende Systeme die BNetzA-VL aktualisieren müssen. In TUC_PKI_030 (GS-A_4750-02) ist geregelt, wie diese Systeme Prüfungen von QES-Zertifikaten durchführen müssen. Dabei wird jeweils auf den zu verwendenden ETSI-Standard verwiesen. Aufgrund der oben beschriebenen Veränderungen werden entsprechende Anpassungen an den Spezifikationen mit Hinweisen auf den neueren Standard ETSI TS 119 612 v.2.3.1 (von 11/2024) vorgenommen.
2 Änderung in gemSpec_PKI
2.1.1 Kapitel 8.5.2 TUC_PKI_036 „BNetzA-VL Aktualisierung“
GS-A_5484-01 - TUC_PKI_036 „BNetzA-VL-Aktualisierung“
Alle Produkttypen, die die BNetzA-VL verwenden, MÜSSEN TUC_PKI_036 zur Aktualisierung umsetzen.
Tabelle 1: TUC_PKI_036 „BNetzA-VL Aktualisierung“
| Element |
Beschreibung |
|---|---|
| Name |
TUC_PKI_036 „BNetzA-VL Aktualisierung“ |
| Beschreibung |
Dieser Use Case beschreibt die Aktualisierung der im System gespeicherten BNetzA-VL. |
| Anwendungsumfeld |
System, das die BNetzA-VL verwendet |
| Vorbedingungen |
Eine aktuell gültige TSL im System |
| Auslöser |
Produkttypspezifischer Trigger |
| Eingangsdaten |
|
| Komponenten |
System |
| Ausgangsdaten |
Status des Prozesses |
| Referenzen |
[ETSI_TS_119_612]. [XML] [XMLSig] |
| Standardablauf |
Der Standardablauf stellt die Prüfungen dar, die vollzogen werden müssen. Die Reihenfolge der Schritte ist aber nicht normativ. Eine Trennung in zwei Prozesse oder eine Umstrukturierung, bei der alle notwendigen Prüfungen erfolgen, ist zulässig. 1. [System:] System startet die Aktualisierung der BNetzA-VL 2. [System:] Primäre BNetzA-VL Hash Download-Adresse aus der TSL extrahieren (s. [gemSpec_TSL#7.5]). 3. [System:] Von der im vorherigen Schritt ermittelten Downloadadresse den aktuellen BNetzA-VL Hashwert vom TSL-Dienst herunterladen. 4. [System:] Heruntergeladenen BNetzA-VL Hashwert mit dem Hashwert der aktuell im System gespeicherten BNetzA-VL (falls vorhanden) vergleichen. Falls die Hashwerte verschieden sind oder im System noch keine BNetzA-VL vorhanden ist muss die BNetzA-VL im System aktualisiert werden. 5. [System:] Primäre BNetzA-VL Download-Adresse aus der TSL extrahieren (s. [gemSpec_TSL#7.5]). 6. [System:] Von der ermittelten Downloadadresse die aktuelle BNetzA-VL vom TSL-Dienst herunterladen. 7. [System:] Die Wohlgeformtheit der BNetzA-VL-Datei prüfen. 8. [System:] Die BNetzA-VL-Datei gegen das XML-Schema gem. [ETSI_TS_119_612#Annex C.2] validieren (Hierzu muss das in Annex C.2 referenzierte XML-Schema für die Validierung verwendet werden). 9. [System:] Die Aktualität der BNetzA-VL prüfen. Dies geschieht anhand des aktuellen Datums und des Elements „NextUpdate“ aus der BNetzA-VL. Die BNetzA-VL wird als aktuell bezeichnet, wenn ihr NextUpdate nicht in der Vergangenheit liegt. 10. [System:] Das verwendete BNetzA-VL-Signer-Zertifikat aus der BNetzA-VL-Datei extrahieren. 11. [System:] Prüfen ob das BNetzA-VL-Signerzertifikat in der TSL enthalten ist. Die Identifizierung des Zertifikats erfolgt durch
[System:] Die XML-Signatur der BNetzA-VL-Datei mittels in der TSL gefundenem BNetzA-VL-Signerzertifikat gem. [XAdES] prüfen. 13. [System:] Die aktualisierte BNetzA-VL und deren Hashwert (falls vorhanden) sicher im System speichern. Ende des Use Cases. |
| Varianten/Alternativen |
1a. System:] Wenn eine BNetzA-VL-Datei als Eingangsparameter eingebracht wurde, dann wird diese Datei validiert und geprüft. Weiter mit Schritt 7. 2a. [System:] Das Element ist nicht vorhanden. Weiter mit Schritt 3a.2 3a. [System:] Das Herunterladen von der primären Downloadadresse schlägt fehl. 3a.1 [System:] Das Herunterladen wird bis zu drei Mal wiederholt versucht (insgesamt wird der Vorgang also maximal vier Mal ausgeführt). Falls erfolgreich, weiter mit Schritt 4. 3a.2 [System:] Backup BNetzA-VL Hash Download-Adresse aus der TSL extrahieren (s. [gemSpec_TSL#7.5]). Falls nicht erfolgreich, weiter mit Schritt 5. 3a.3 [System:] Das Herunterladen wird von der Backup Downloadadresse ausgeführt. Falls erfolgreich, weiter mit Schritt 4. 3a.4 [System:] Das Herunterladen von der Backup Downloadadresse wird bis zu drei Mal wiederholt versucht (insgesamt wird der Vorgang also maximal vier Mal ausgeführt). Falls erfolgreich, weiter mit Schritt 4. Falls nicht erfolgreich, weiter mit Schritt 5. 4a. [System:] Die verglichenen Hashwerte sind identisch. In diesem Fall ist die im System gespeicherte BNetzA-VL aktuell. Ende des Use Cases ohne Fehler. 5b. [System:] Das Element ist nicht vorhanden. Weiter mit Schritt 6a.2 6a. [System:] Das Herunterladen von der primären Downloadadresse schlägt fehl. 6a.1 [System:] Das Herunterladen wird bis zu drei Mal wiederholt versucht (insgesamt wird der Vorgang also maximal vier Mal ausgeführt). Falls erfolgreich, weiter mit Schritt 7. 6a.2 [System:] Backup BNetzA-VL Download-Adresse aus der TSL extrahieren (s. [gemSpec_TSL#7.5]). 6a.3 [System:] Das Herunterladen wird von der Backup Downloadadresse ausgeführt. Falls erfolgreich, weiter mit Schritt 7. 6a.4 [System:] Das Herunterladen von der Backup Downloadadresse wird bis zu drei Mal wiederholt versucht (insgesamt wird der Vorgang also maximal vier Mal ausgeführt). Falls erfolgreich, weiter mit Schritt 7. |
| Fehlerfälle |
Ein Abbruch des TUC führt nur dazu, dass keine neue BNetzA-VL gespeichert wird. Er hat keinen Einfluss auf die Gültigkeit der bestehenden BNetzA-VL. Das System muss dies jedoch protokollieren. 6a.2a [System:] Das Element ist nicht vorhanden. Ende des Use Case mit der Fehlermeldung VL_UPDATE_ERROR. 6a.4a [System:] Das Herunterladen der BNetzA-VL ist fehlgeschlagen. Ende des Use Cases mit der Fehlermeldung VL_UPDATE_ERROR. 7a. [System:] Die XML-Datei ist nicht wohlgeformt. Ende des Use Cases mit der Fehlermeldung VL_UPDATE_ERROR. 8a. [System:] Die XML-Schema-Validierung liefert einen Fehler. Ende des Use Cases mit der Fehlermeldung VL_UPDATE_ERROR. 9a. [System:] Die Aktualitäts-Prüfung ergibt, dass die BNetzA-VL abgelaufen ist (nextUpdate < aktuelles Datum). Ende des Use Cases mit der Fehlermeldung VL_UPDATE_ERROR. 10a. [System:] Das BNetzA-VL-Signer-Zertifikat lässt sich nicht aus der BNetzA-VL-Datei extrahieren. Ende des Use Cases mit der Fehlermeldung VL_UPDATE_ERROR. 11a. BNetzA-VL-Signerzertifikat ist nicht in der TSL enthalten. Ende des Use Case mit der Fehlermeldung VL_UPDATE_ERROR. 12a. [System:] Die Signatur ist nicht gültig. Ende des Use Cases mit der Fehlermeldung XML_SIGNATURE_ERROR. |
| Sicherheitsanforderungen |
Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen. |
| Anmerkungen |
Das BNetzA-VL-Signer-Zertifikat wird vor Aufnahme in die TSL geprüft (s. [gemSpec_TSL#6.3]). Diese Prüfschritte werden darum nach dem Download innerhalb der TI nicht wiederholt. |
| Zugehörige Diagramme |
[<=]
2.1.2 Kapitel 8.5.1 TUC_PKI_030 „QES-Zertifikatsprüfung“
GS-A_4750-02 - TUC_PKI_030 „QES-Zertifikatsprüfung“
Alle Produkttypen, die QES-Zertifikate prüfen, MÜSSEN TUC_PKI_030 zur Prüfung der QES-Zertifikate umsetzen.
Tabelle 2: TUC_PKI_030 „QES-Zertifikatsprüfung“
| Element |
Beschreibung |
|---|---|
| Name |
TUC_PKI_030 „QES-Zertifikatsprüfung“ |
| Beschreibung |
In diesem Use Case wird die Prüfung von Zertifikaten mit qualifizierter Signatur beschrieben. Die Prüfung von QES-Zertifikaten und die Sperrprüfung per OCSP entsprechen den gesetzlichen Vorgaben und relevanten Standards. Die zugrundeliegende Prüfung des Zertifikatspfads (Validation Certificate Path) basiert auf dem Kettenmodell (chain model), siehe Anmerkung [1]. Zusätzlich werden folgende Schritte in diesem Technical Use Case (TUC) durchgeführt. |
| Anwendungsumfeld |
System, das Zertifikate verwendet |
| Vorbedingungen |
aktuelle TSL-Informationen im Truststore (inkl. OCSP-Adressen in der TI für die zugelassenen VDAs), eine aktuell gültige BNetzA-VL. |
| Auslöser |
Zertifikats-Check |
| Eingangsdaten |
|
| Komponenten |
System |
| Ausgangsdaten |
|
| Referenzen | [eIDAS], [VDG], [ETSI TS 119 612] (neue Version 2.3.1 (Stand November 2024), [ETSI EN 319 412-5], [ETSI EN 319 412-2], [ETSI EN 319 102-1], [ETSI TS 119 172-4] [RFC5280], [RFC6960], [RFC5019] |
| Standardablauf |
1. [System:] Auslesen und Ausgabe aller gesetzten Elemente der Extension QCStatements des Zertifikates, Details siehe Anmerkung [3]. 2. [System:] Prüfung der (zeitlichen) Gültigkeit des Zertifikats mittels TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats", Details siehe Anmerkung [4]. 3. [System:] Prüfung der Extension KeyUsage auf Vorhandensein und die richtige Belegung entsprechend [ETSI EN 319 412-2], Details siehe Anmerkung [5]. 4. [System:] Anhand der End-Entity-Zertifikate wird die BNetzA-VL durchsucht, um das passende QES-CA-Zertifikat zu finden. 5. [System:] Prüfung, ob das ausstellende QES-CA-Zertifikat für die QES-Prüfung zum Zeitpunkt der Erstellung des End-Entity-Zertifikats in der BNetzA-VL gemäß [eIDAS] und [ETSI TS 119 612 qualifiziert und als gültig gekennzeichnet ist, Details siehe Anmerkung [7]. 6. [System:] Prüfung der mathematischen Signaturkorrektheit des Signaturzertifikats zum übergebenen Referenzzeitpunkt gegen das CA-Zertifikat aus Schritt 5 nach dem Kettenmodell, Details siehe Anmerkungen [1], [9]. 7. [System:] Ermittlung der OCSP-Adresse aus dem AIA-Feld des QES-EE-Zertifikates. Dabei handelt es sich um eine öffentlich aufrufbare URL im Internet. Wird für die ermittelte OCSP-URL in der TSL derselbe Wert im InformationValue-Element von AdditionalServiceInformation von BNetzA-VL-Service (mit ServiceTypeIdentifier http://uri.telematik/TrstSvc/Svctype/TrustedList/schemerules/DE) gefunden, so wird die dahinter folgende (nach Leerzeichen) URL als Adresse für die OCSP-Anfrage verwendet. Andernfalls wird die zuvor ermittelte OCSP-Adresse aus dem AIA-Feld für die OCSP-Anfrage verwendet, Details siehe Anmerkung [10]. 8. [System:] Die abzufragenden Statusinformationen zu QES-Zertifikaten werden per OCSP-Requests unter Verwendung der aus der TSL ermittelten OCSP-Adresse aus Schritt 7 eingeholt. 9. Prüfung der OCSP-Response auf Integrität [System, OCSP-Responder:] Das dazu benötigte OCSP-Responder-Zertifikat (OCSP-Signer-Zertifikat) wird aus dem URI (markiert mit dem ServiceTypeIdentifier http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP oder http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP/QC) in der BNetzA-VL ermittelt. Die Signatur der OCSP-Response wird zum Referenzzeitpunkt mittels des ermittelten OCSP-Signer-Zertifikats geprüft. Falls keiner der URIs vorhanden ist, wird weiter mit Schritt 10 verfahren, siehe Anmerkung [12]. 10. [System, OCSP-Responder:] Das OCSP-Signer-Zertifikat aus dem Feld „certs“ in der OCSP-Response ermitteln. Die Signatur des OCSP-Signer-Zertifikats wird entsprechend mittels des im Schritt 6 validierten QES-CA-Zertifikats geprüft. Die Signatur der OCSP-Response wird anschließend mittels des ermittelten OCSP-Signer-Zertifikats geprüft, siehe Anmerkungen [12]. 11. [System] Auswertung der OCSP-Respone. Dies umfasst die Prüfung gemäß Standards (Details siehe Anmerkung [11])
[System:] Überprüfung der Gültigkeit der Statusinformation anhand des übergegebenen Referenzzeitpunkts. Der certStatus „good“ wird gemeldet. Rückmeldung „Das Zertifikat ist gültig“ und Rückgabe der OCSP-Response. 13. [System:] Ermittlung der Rolle (TUC_PKI_009 "Rollenermittlung") 14. [System:] Ende des Use Case mit Rückgabe des/der im Zertifikat enthaltenen Rollen-OID(s) |
| Varianten/Alternativen |
Der Standardablauf stellt die üblichen Schritte dar, die durchgeführt werden müssen. Eine Trennung in zwei Prozesse oder eine Umstrukturierung, bei der alle notwendigen Schritte erfolgen, ist zulässig. 7a. [System:] Der Offline-Modus ist aktiviert. Es werden keine Statusinformationen eingeholt. (Schritte 8, 9, 10, 11 und 12 entfallen) 8a. [System:] Wird im optionalen Parameter Nonce ein Wert übergeben, dann muss für QES-Zertifikate dieser Wert als OCSP-Parameter in den OCSP-Request integriert und im Response geprüft werden. 8b. [System:] Eine OCSP-Response zu dem zu prüfenden Zertifikat wurde im Aufruf mit übergeben. Falls dieses zum Referenzzeitpunkt gültig ist, werden keine OCSP-Requests erzeugt, sondern die beigefügte OCSP-Response zur weiteren Prüfung verwendet. |
| Fehlerfälle/Warnung |
In jedem der beschriebenen Schritte können Fehler auftreten. Diese sind durch das System zu melden und der Prozess muss beendet werden. 1a. Ist die Extension QCStatements nicht auslesbar, leer oder enthält keine auslesbaren Elemente, bricht der TUC mit dem Fehler QC_STATEMENT_ERROR ab. 3a. [System:] KeyUsage ist nicht vorhanden bzw. entspricht nicht der vorgesehenen keyUsage (WRONG_KEYUSAGE) 5a. Ist das QES-CA-Zertifikat in der BNetzA-VL nicht vorhanden oder zum Referenzzeitpunkt nicht mit einem gültigen Status gekennzeichnet, muss der TUC mit einer Fehlermeldung CA_CERTIFICATE_NOT_QES_QUALIFIED abbrechen. 5b. [System:] QES-CA-Zertifikat des QES-Zertifikates ist in der BNetzA-VL als revoked gekennzeichnet und QES-Zertifikat ist nach Sperrzeitpunkt erstellt worden. Abbruch mit Fehlermeldung (CA_CERTIFICATE_REVOKED_IN_BNETZA-VL). 6a. [System] Die Zertifikats-Signatur ist nicht gültig. Ende des Use Case. Abbruch mit Fehlermeldung (CERTIFICATE_NOT_VALID_MATH) 7b. [System:] Warnmeldung, dass keine Online-Statusprüfung durchgeführt wurde (NO_OCSP_CHECK). 8c. [System:]. Der zuständige OCSP-Responder ist nicht erreichbar. Abbruch mit Fehlermeldung ( OCSP_NOT_AVAILABLE). 8d. [System:] OCSP-Responses zu dem zu prüfenden Zertifikat wurden im Aufruf mit übergeben, ergaben bei den weiteren Prüfschritten jedoch kein gültiges Ergebnis. Eine erneute Prüfung wird in diesem Fall durchgeführt, als wären keine OCSP-Responses beigefügt. In den Rückgabewerten dieses TUC wird die Warnmeldung (PROVIDED_OCSP_RESPONSE_NOT_VALID) an die aufrufende Funktion übergeben. 8e. Wenn die in einer OCSP-Response zurückgelieferte Nonce nicht mit der Nonce des OCSP-Requests für ein QES-Zertifikat übereinstimmt, wird die Prüfung abgebrochen mit der Fehlermeldung OCSP_NONCE_MISMATCH. 8f. [System] Nach zeitlichem Ablauf der TSL-Graceperiod ist die aus der TSL zu ermittelnde OCSP-Adresse nicht mehr vertrauenswürdig. Abbruch mit Fehlermeldung (OCSP_CHECK_REVOCATION_ERROR). 9a/10a. [System:] OCSP-Signer-Zertifikat nicht in der OCSP-Response enthalten. Abbruch mit Fehlermeldung. (OCSP_CERT_MISSING). 9a1/10a1. [System] Signatur der OCSP-Response ist nicht gültig. Abbruch mit Fehlermeldung (OCSP_SIGNATURE_ERROR) 11a. [System] Die Response enthält einen Statuscode („OCSPResponseStatus“), der ungleich 0 (für „successful“) ist. (Damit zeigt der OCSP-Responder eine Exception an. Beispielsweise kann der Wert für den Status auf 3 für „tryLater“ gesetzt sein.) Abbruch mit Fehlermeldung (OCSP_STATUS_ERROR) 11b. [System] Die Response enthält einen Statuscode („OCSPResponseStatus“), der gleich 0 („successful“) ist. Die ausgewertete OCSP-Response passt aber nicht zum OCSP-Request (z.B. CertID in OCSP-Request und -Response stimmt nicht überein, s. a. Anmerkung [13]). Abbruch mit Fehlermeldung (OCSP_CHECK_REVOCATION_ERROR) 12a. [System:] Das Zertifikat ist für den Referenzzeitpunkt gültig, obwohl der CertStatus "revoked“ gemeldet wird, da "revocationTime“ > Referenzzeitpunkt. Rückmeldung Zertifikat ist für den Referenzzeitpunkt gültig und Rückgabe der OCSP-Response, siehe Anmerkung [14]. 12b. [System:] Zertifikat ist gesperrt und die Referenzzeit liegt nach dem Sperrzeitpunkt (CertStatus revoked UND revocationTime <= Referenzzeitpunkts). Rückmeldung Zertifikat ist gesperrt und Rückgabe der OCSP-Response. (CERT_REVOKED) 12c. [System:] Zertifikat ist unbekannt (Status unknown) Rückmeldung, dass das Zertifikat ungültig ist und Rückgabe der OCSP-Response. (CERT_UNKNOWN) Weitere Fehlerfälle werden in den jeweiligen referenzierten Use Cases beschrieben. |
| Sicherheitsanforderungen |
Es gelten die allgemeinen Sicherheitsanforderungen an die Produkttypen der TI, die QES-Zertifikate prüfen, siehe auch [RFC6960] Kap. 5. |
| Anmerkungen |
Folgende Hinweise sollen als Hilfestellung für eine Umsetzung des TUC dienen: [1] Kettenmodell (chain model) für die Validierung von QES-X.509-Zertifikatketten: Alle CA-Zertifikate müssen zum Zeitpunkt der Ausstellung eines QES-EE-Zertifikats gültig sein und das Zertifikat war beim Erstellen der qualifizierten Signatur gültig und nicht von der CA gesperrt, s. Artikel 32, Absatz (1), Satz (b) [eIDAS], Definition Kettenmodell s. [ETSI TR 119 001], Verwendung v. Prüfmodellen s. [ETSI EN 319 102-1] Kap. 5.2.6.4. [2]Weiterführende Informationen siehe Glossar aus Kap. 11.2 und Definition der Zeitparameter aus [gemSpec_Kon] Kap. 4.1.8.1.3. [3] Schritt 1: Im Signaturzertifikat muss mindestens ein QCStatement mit dem OID id-etsi-qcs-QcCompliance. (0.4.0.1862.1.1) enthalten sein. Die QC-Statement-Typen werden in ETSI EN 319 412-5, insbesondere Kap. 5 – Table 2 für QES-Zertifikate, bezüglich der Extension QCStatements des Zertifikates beschrieben. [4] Schritt 2: Die (zeitliche) Gültigkeitsprüfung ist nach [eIDAS] Artikel 28 Satz (1) ANHANG I Buchstabe e) auch für die QES-Zertifikatsprüfung gemäß TUC_PKI_030 verpflichtend, s. a. [ETSI EN 319 412-5] Annex A.1 Buchstabe (e). [5] Schritt 3: Die Prüfung der KeyUsage lehnt sich an [RFC5280] Kap. 4.2.1.3 und [ETSI EN 319 412-2] Kap. 4.3.2 – Table 1 (KeyUsage v. Type A) sowie Tab_PKI_270. [6] Schritt 4: Das Verfahren zum Finden des QES-CA-Zertifikates in BNetzA-VL verläuft analog zum Finden des nonQES-CA-Zertifikates in der TSL mittels TUC_PKI_003. [7] Schritt 5: Gültigkeitsstatus einer QES-CA wird gemäß [ETSI TS 119 612] Kap. 5.5.4 und Annex J durch den Servicestatus granted und withdrawn in der BNetzA-VL gekennzeichnet. Pre-eIDAS-relevante Servicestatus (undersupervision, supervisionincessation oder accredited) werden in granted bzw. (supervisionceased oder supervisionrevoked") in withdrawn überführt. Historien zum Servicestatus v. VDAs, hinterlegt im Element <ServiceHistory> in der BNetzA-VL, sind bei der Prüfung der CA zu berücksichtigen. [8] Die Einträge der QES-CA-Zertifikate in der BNetzA-VL besitzen gemäß [ETSI TS 119 612] Kap. 5.5.9.4 die Extension additionalServiceInformation http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSignatures. [9] Schritt 6: Die Prüfung der Korrektheit der digitalen Signatur des Signaturzertifikats ist z.B. gemäß FDP_DAU.2/QES aus [BSI-CC-PP-0098] ein Bestandteil der QES-Prüfung, welcher sich nicht aus TUC_PKI_004 ableiten lässt. [10] Schritt 7:
[14] Schritt 12a: Falls die Referenzzeit nicht übergeben wird, wird die aktuelle Systemzeit verwendet. Die Variante 12a. ist unter diesen Umständen nicht möglich; sie wird also nicht berücksichtigt. |
| Zugehörige Diagramme/Tabelle |
[<=]
2.1.3 Kapitel 11.5.2 Weitere Dokumente
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
|---|---|
| ... | |
| [ETSI TS 119 612] |
ETSI (2024-11): ETSI TS 119 612 ‘Electronic Signatures and Infrastructures (ESI); Trusted Lists’, Version 2.3.1 https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.03.01_60/ts_119612v020301p.pdf Hinweis: Das in Annex C.2 referenzierte XML-Schema muss für die Validierung verwendet werden https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_xsd.xsd https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_sie_xsd.xsd https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_additionaltypes_xsd.xsd |
| ... |
3 Änderung in gemKPT_PKI_TIP
In Erstellung
3.1.1 Kapitel 8.5.2 Weitere Dokumente
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
|---|---|
| ... | |
| [ETSI_TS_119 _612] |
ETSI (2024-11): ETSI TS 119 612 ‘Electronic Signatures and Infrastructures (ESI); Trusted Lists’, Version 2.3.1 https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.03.01_60/ts_119612v020301p.pdf Hinweis: Das in Annex C.2 referenzierte XML-Schema muss für die Validierung verwendet werden https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_xsd.xsd https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_sie_xsd.xsd https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_additionaltypes_xsd.xsd |
| ... |
4 Änderung in gemSpec_TSL
4.1.1 8.5.2 Weitere Dokumente
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
|---|---|
| ... |
... |
| [ETSI_TS_119_612] |
ETSI (2024-11): ETSI TS 119 612 ‘Electronic Signatures and Infrastructures (ESI); Trusted Lists’, Version 2.3.1 https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.03.01_60/ts_119612v020301p.pdf Hinweis: Das in Annex C.2 referenzierte XML-Schema muss für die Validierung verwendet werden https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_xsd.xsd https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_sie_xsd.xsd https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.3.1/19612_additionaltypes_xsd.xsd |
| ... |
... |
5 Änderungen in Steckbriefen
Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_...]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.
5.1 Änderungen in gemProdT_eRp_FD
Tabelle 3:
| Afo-ID (gemSpec_PKI) |
Afo-Bezeichnung |
Prüfverfahren |
|---|---|---|
| GS-A_5484-01 |
TUC_PKI_036 „BNetzA-VL-Aktualisierung“ |
Anforderungen zur Sich.techn. Eignung: Produktgutachten |
| GS-A_4750-02 | TUC_PKI_030 „QES-Zertifikatsprüfung“ | Anforderungen zur funktionalen Eignung: Test Produkt/FA und zur Sich.techn. Eignung: Produktgutachten |
5.2 Änderungen in gemProdT_Kon_Highspeed
Tabelle 4:
| Afo-ID (gemSpec_PKI) |
Afo-Bezeichnung |
Prüfverfahren |
|---|---|---|
| GS-A_5484-01 |
TUC_PKI_036 „BNetzA-VL-Aktualisierung“ |
Anforderungen zur funktionalen Eignung: Test Produkt/FA |
| GS-A_4750-02 | TUC_PKI_030 „QES-Zertifikatsprüfung“ | Anforderungen zur funktionalen Eignung: Test Produkt/FA und zur Sich.techn. Eignung: Prüfung durh CC-Prüfstelle |
5.3 Änderungen in gemProdT_Kon_PTV5Plus
Tabelle :
| Afo-ID (gemSpec_PKI) |
Afo-Bezeichnung |
Prüfverfahren |
|---|---|---|
| GS-A_5484-01 |
TUC_PKI_036 „BNetzA-VL-Aktualisierung“ |
Anforderungen zur funktionalen Eignung: Test Produkt/FA |
| GS-A_4750-02 | TUC_PKI_030 „QES-Zertifikatsprüfung“ | Anforderungen zur funktionalen Eignung: Test Produkt/FA und zur Sich.techn. Eignung: CC-Evaluierung |
5.4 Änderungen in gemProdT_Kon_PTV6
Tabelle :
| Afo-ID (gemSpec_PKI) |
Afo-Bezeichnung |
Prüfverfahren |
|---|---|---|
| GS-A_5484-01 |
TUC_PKI_036 „BNetzA-VL-Aktualisierung“ |
Anforderungen zur funktionalen Eignung: Test Produkt/FA |
| GS-A_4750-02 | TUC_PKI_030 „QES-Zertifikatsprüfung“ | Anforderungen zur funktionalen Eignung: Test Produkt/FA und zur Sich.techn. Eignung: CC-Evaluierung |