Volkswagen Vehicle Public Key Infrastructure · CP für Root-CA der Product Legacy PKI, P, Serie, Version 1.19 1/77 . Volkswagen Group Product Legacy Public Key Infrastructure - Certificate

CP für Root-CA der Product Legacy PKI, P, Serie, Version 1.19 1/77

Volkswagen Group Product Legacy

Public Key Infrastructure

- Certificate Policy (CP) für die Legacy

Root-CA der Produktiv-PKI für Serien-

komponenten -


Dokumenten-Eigenschaften Projekt Volkswagen Product Legacy Public Key Infrastructure (PKI) Sub-Projekt Dokumentation Dokument CP der Legacy Root-CA der Produktiv-Instanz der Product PKI für Serienkomponenten Kapitel Dokumenten-ID OID ohne Version: 1.3.6.1.4.1.3210.8009.20.2.1.4.1.0.1.2 Autor Uwe-Jens Hofmann OrgEinheit K-SIS-O/2 Version 1.19 Status Freigegeben Datum 18.03.2020 Einstufung Öffentlich

Dokumenten-Verteilung Name Marke Einheit

Änderungshistorie Datum Autor Bemerkungen 1.0 2017-08-01 Uwe-Jens Hofmann Erstversion

1.0.1 2018-08-13 Martin Grothues Anpassung OID

1.0.2 2018-08-17 Martin Grothues Diverse Korrekturen

1.0.3 2018-08-23 Martin Grothues Anpassungen Kapitel 1.3

1.0.4 2018-10-10 Martin Grothues Einfügen Punkt 4.9.1

1.0.5 2019-01-25 Martin Grothues Synchronisation mit Product ROOT-CP und kleine Korrekturen/Erweiterungen

1.0.6 2019-01-29 Martin Grothues Anpassung Abschnitt 6

1.0.7 2019-02-05 Martin Grothues Anpassungen 4.9.1 und 5.2.4

1.0.8 2019-03-25 Martin Grothues Anpassungen 4.1.1 und Abschnitt 6

1.0.9 2019-03-26 Martin Grothues Diverse Korrekturen

1.10 2019-03-28 Martin Grothues Anpassung 7.2 + OCSP-Stapling


1.11 2019-03-28 Martin Grothues Anpassungen 4.9.12 – 4.9.16

1.12 2019-04-05 Martin Grothues Diverse Einfügungen in Abschnitt 9

1.13 2019-04-18 Martin Grothues Diverse Überarbeitungen und Synchronisation PRDCT und PRLGC ROOT-CA CP

1.14 14.05.2019 Martin Grothues Diverse Korrekturen und Sync mit Product-CP

1.15 14.05.2019 Martin Grothues Freigabe durch das CCPP

1.16 21.08.2019 Martin Grothues Änderung Abschnitt 4.4 (Zertifikatsübergabe) und kleinere Korrekturen

1.17 03.09.2019 Martin Grothues Korrekturen 1.3.5 Zertifikatsnutzer

1.18 18.10.2019 Martin Grothues Einfügung 4.9.13

1.19 18.03.2020 Martin Grothues Einfügen Logo und Wasserzeichen


Inhalt Vorbemerkungen: ...............................................................................................................14

1 EINLEITUNG .................................................................................................................15

1.1 Überblick .................................................................................................................15

1.1.1 Zertifikatstypen ..................................................................................................15

1.1.2 Struktur des Dokuments ....................................................................................16

1.1.3 Konventionen / Nomenklatur .............................................................................16

1.2 Dokumentenname und Identifikation ........................................................................17

1.3 PKI Teilnehmer ........................................................................................................17

1.3.1 Zertifizierungsstellen (CA) .................................................................................17

1.3.2 Registrierungsstellen (RA) ................................................................................18

1.3.3 Zertifikatsinhaber ...............................................................................................19

1.3.4 Zertifikatsnehmer ..............................................................................................19

1.3.5 Zertifikatsnutzer.................................................................................................20

1.4 Verwendung von Zertifikaten ...................................................................................21

1.4.1 Erlaubte Verwendung von Zertifikaten ...............................................................21

1.4.2 Untersagte Verwendung von Zertifikaten ..........................................................21

1.5 Verwaltung der Richtlinie .........................................................................................21

1.5.1 Änderungsmanagement ....................................................................................21

1.5.2 Ansprechpartner................................................................................................21

1.5.3 Eignungsprüfer zur Feststellung der Regelkonformität eines CPS ....................22

1.5.4 Verfahren zur Freigabe eines CPS ....................................................................22

1.6 Begriffe und Akronyme ............................................................................................22

2 VERANTWORTLICHKEITEN FÜR VERZEICHNISSE UND VERÖFFENTLICHUNGEN...................................................................................................29

2.1 Verzeichnisse ..........................................................................................................29

2.2 Veröffentlichungen von Informationen zur Zertifikatserstellung ................................29

2.3 Zeitpunkt und Häufigkeit von Veröffentlichungen .....................................................29

2.4 Zugriffskontrolle auf Verzeichnisse ..........................................................................30


3 IDENTIFIKATION UND AUTHENTIFIZIERUNG ............................................................31

3.1 Namensregeln .........................................................................................................31

3.1.1 Namensformen .................................................................................................31

3.1.2 Notwendigkeit aussagekräftiger Namen ............................................................31

3.1.3 Anonymität bzw. Pseudonymität von Zertifikatsnehmern ...................................31

3.1.4 Regelungen zur Interpretation verschiedener Namensformen ...........................31

3.1.5 Eindeutigkeit von Namen ..................................................................................31

3.1.6 Anerkennung, Authentifizierung und Funktion von Warenzeichen .....................32

3.2 Identitätsprüfung bei Erstantrag ...............................................................................32

3.2.1 Nachweis des Besitzes des privaten Schlüssels ...............................................32

3.2.2 Authentifizierung von Organisationen ................................................................32

3.2.3 Authentifizierung natürlicher Personen ..............................................................32

3.2.4 Nicht überprüfte Teilnehmerangaben natürlicher Personen ...............................32

3.2.5 Überprüfung der Berechtigungen ......................................................................32

3.2.6 Kriterien zur Interoperabilität .............................................................................33

3.3 Identifizierung und Authentifizierung von Zertifikatsanträgen nach

Schlüsselerneuerung .........................................................................................................33

3.3.1 Routinemäßige Zertifizierung neuer Schlüssel ..................................................33

3.3.2 Zertifizierung neuer Schlüssel nach einer Sperrung des alten Zertifikats ...........33

3.4 Identifizierung und Authentifizierung von Sperranträgen ..........................................33

4 ABLAUFORGANISATION (Zertifikats-Lebenszyklus) ................................................35

4.1 Zertifikatsantrag .......................................................................................................35

4.1.1 Berechtigung zur Antragsstellung ......................................................................35

4.1.2 Registrierungsprozess und Zuständigkeiten ......................................................35

4.2 Verarbeitung des Zertifikatsantrags .........................................................................36

4.2.1 Durchführung der Identifizierung und Authentifizierung .....................................36

4.2.2 Annahme oder Ablehnung von Zertifikatsanträgen ............................................36

4.2.3 Fristen für die Bearbeitung von Zertifikatsanträgen ...........................................36

4.3 Zertifikatsausstellung ...............................................................................................36


4.3.1 Aktionen der Zertifizierungsstelle (CA) bei der Ausstellung von Zertifikaten ......36

4.3.2 Benachrichtigung des Zertifikatsnehmers über die Ausstellung des

Zertifikats .......................................................................................................................36

4.4 Zertifikatsübergabe ..................................................................................................37

4.4.1 Verhalten bei der Annahme/Übergabe eines Zertifikats.....................................37

4.4.2 Veröffentlichung eines Zertifikates durch die CA ...............................................37

4.4.3 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines

Zertifikats .......................................................................................................................37

4.5 Verwendung des Schlüsselpaars und des Zertifikats ...............................................37

4.5.1 Verwendung des privaten Schlüssels und des Zertifikats durch den

Zertifikatsnehmer (Zertifikatsinhaber) .............................................................................37

4.5.2 Verwendung des öffentlichen Schlüssels und des Zertifikats durch den

Zertifikatsnutzer .............................................................................................................38

4.6 Zertifikatserneuerung ...............................................................................................38

4.6.1 Bedingungen für eine Zertifikatserneuerung ......................................................38

4.6.2 Berechtigung zur Beantragung einer Zertifikatserneuerung ...............................38

4.6.3 Bearbeitungsprozess eines Antrags auf Zertifikatserneuerung ..........................38

4.6.4 Benachrichtigung des Zertifikatsnehmers über die Ausgabe eines neuen

Zertifikats .......................................................................................................................38

4.6.5 Verhalten für die Annahme einer Zertifikatserneuerung .....................................39

4.6.6 Veröffentlichung der Zertifikatserneuerung durch die CA ..................................39

4.6.7 Benachrichtigung anderer PKI-Teilnehmer über die Erneuerung des

Zertifikats .......................................................................................................................39

4.7 Zertifizierung nach Schlüsselerneuerung .................................................................39

4.7.1 Bedingungen für eine Zertifizierung nach Schlüsselerneuerung ........................39

4.7.2 Berechtigung zur Schlüsselerneuerung .............................................................39

4.7.3 Bearbeitung von Zertifikatsanträgen für Schlüsselerneuerungen .......................39

4.7.4 Benachrichtigung des Zertifikatsnehmers über die Ausgabe eines

Nachfolgezertifikats ........................................................................................................39

4.7.5 Verhalten für die Annahme von Zertifikaten nach Schlüsselerneuerungen ........39


4.7.6 Veröffentlichung von Zertifikaten nach Schlüsselerneuerungen durch die

CA 39

4.7.7 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines

Nachfolgezertifikats ........................................................................................................40

4.8 Zertifikatsänderung ..................................................................................................40

4.8.1 Bedingungen für eine Zertifikatsänderung .........................................................40

4.8.2 Wer darf eine Zertifikatsänderung beantragen? ................................................40

4.8.3 Bearbeitung eines Antrags auf Zertifikatsänderung ...........................................40

4.8.4 Benachrichtigung des Zertifikatsnehmers über die Ausgabe eines neuen

Zertifikats .......................................................................................................................40

4.8.5 Verhalten für die Annahme einer Zertifikatsänderung ........................................40

4.8.6 Veröffentlichung der Zertifikatsänderung durch die CA......................................40

4.8.7 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines neuen

Zertifikats .......................................................................................................................40

4.9 Sperrung und Suspendierung von Zertifikaten .........................................................40

4.9.1 Bedingungen für eine Sperrung .........................................................................41

4.9.2 Berechtigte zur Beantragung einer Sperrung ....................................................44

4.9.3 Verfahren für einen Sperrantrag ........................................................................44

4.9.4 Fristen für einen Sperrantrag.............................................................................44

4.9.5 Fristen/Zeitspanne für die Bearbeitung des Sperrantrags durch die CA ............44

4.9.6 Verfügbare Methoden zum Prüfen von Sperrinformationen ...............................44

4.9.7 Frequenz der Veröffentlichung von Sperrlisten ..................................................45

4.9.8 Maximale Latenzzeit für Sperrlisten...................................................................45

4.9.9 Verfügbarkeit von Online-Sperrinformationen ....................................................45

4.9.10 Anforderungen zur Online-Prüfung von Sperrinformationen ...........................45

4.9.11 Andere Formen zur Anzeige von Sperrinformationen .....................................45

4.9.12 Spezielle Anforderungen bei Kompromittierung des privaten Schlüssels .......45

4.9.13 Bedingungen für eine Suspendierung ............................................................45

4.9.14 Berechtigung zur Beantragung einer Suspendierung .....................................45

4.9.15 Verfahren für Anträge auf Suspendierung ......................................................46


4.9.16 Begrenzungen für die Dauer von Suspendierungen .......................................46

4.10 Statusabfragedienst für Zertifikate ........................................................................46

4.10.1 Funktionsweise des Statusabfragedienstes ...................................................46

4.10.2 Verfügbarkeit des Statusabfragedienstes .......................................................46

4.10.3 Optionale Leistungen .....................................................................................46

4.11 Kündigung durch den Zertifikatsnehmer ...............................................................46

4.12 Schlüsselhinterlegung und -wiederherstellung ......................................................46

4.12.1 Bedingungen und Verfahren für die Hinterlegung und Wiederherstellung

privater Schlüssel ...........................................................................................................46

4.12.2 Bedingungen und Verfahren für die Hinterlegung und Wiederherstellung

von Sitzungsschlüsseln (session keys) ..........................................................................47

5 INFRASTRUKTURELLE, ORGANISATORISCHE UND PERSONELLE SICHERHEITSMASSNAHMEN ...........................................................................................48

5.1 Bauliche Sicherheitsmaßnahmen ............................................................................48

5.1.1 Lage und Gebäude ...........................................................................................48

5.1.2 Räumlicher Zugang ...........................................................................................48

5.1.3 Stromversorgung und Klimaanlage ...................................................................49

5.1.4 Gefährdungen durch Wasser ............................................................................49

5.1.5 Brandschutz ......................................................................................................49

5.1.6 Aufbewahrung von Datenträgern .......................................................................49

5.1.7 Müllbeseitigung .................................................................................................49

5.1.8 Externe Datensicherung ....................................................................................49

5.2 Verfahrensvorschriften .............................................................................................49

5.2.1 Rollenkonzept ...................................................................................................49

5.2.2 Mehraugenprinzip .............................................................................................50

5.2.3 Identifizierung und Authentifizierung einzelner Rollen .......................................50

5.2.4 Rollentrennung ..................................................................................................50

5.3 Personalkontrolle .....................................................................................................51

5.3.1 Anforderungen an Qualifikation, Erfahrung und Zuverlässigkeit ........................51

5.3.2 Sicherheitsüberprüfung von Mitarbeitern ...........................................................51


5.3.3 Anforderungen an Schulungen ..........................................................................52

5.3.4 Häufigkeit von Schulungen und Belehrungen ....................................................52

5.3.5 Häufigkeit und Ablauf von Arbeitsplatzwechseln (Job Rotation) ........................52

5.3.6 Sanktionen für unerlaubte Handlungen .............................................................52

5.3.7 Anforderungen an freie Mitarbeiter ....................................................................52

5.3.8 An Mitarbeiter auszuhändigende Dokumentation ..............................................52

5.4 Überwachungs- und Protokollierungsmaßnahmen ..................................................52

5.4.1 Arten aufgezeichneter Ereignisse ......................................................................52

5.4.2 Häufigkeit der Bearbeitung von Aufzeichnungen ...............................................53

5.4.3 Aufbewahrungszeit von Aufzeichnungen ...........................................................53

5.4.4 Schutz von Aufzeichnungen ..............................................................................53

5.4.5 Sicherung von Aufzeichnungen (Backup) ..........................................................53

5.4.6 Speicherung von Aufzeichnungen (intern / extern) ............................................53

5.4.7 Benachrichtigung der Ereignisauslöser .............................................................53

5.4.8 Schwachstellenanalyse .....................................................................................53

5.5 Archivierung von Aufzeichnungen ...........................................................................54

5.5.1 Arten archivierter Aufzeichnungen ....................................................................54

5.5.2 Aufbewahrungsfristen für archivierte Daten .......................................................54

5.5.3 Schutz des Archivs ............................................................................................54

5.5.4 Datensicherung des Archivs (Backup) ...............................................................54

5.5.5 Anforderungen zum Zeitstempeln von Aufzeichnungen .....................................54

5.5.6 Archivierung (intern / extern) .............................................................................54

5.5.7 Verfahren zur Beschaffung und Verifikation von Archivinformationen ................55

5.6 Schlüsselwechsel einer CA......................................................................................55

5.7 Kompromittierung und Notfallplanung ......................................................................56

5.7.1 Behandlung von Vorfällen und Kompromittierungen ..........................................57

5.7.2 Kompromittierung von Rechnerressourcen, Software oder Daten .....................57

5.7.3 Kompromittierung des privaten Schlüssels einer CA .........................................57

5.7.4 Möglichkeiten zur Geschäftsweiterführung nach einer Kompromittierung ..........58


5.8 Schließung von CA oder RA ....................................................................................58

6 TECHNISCHE SICHERHEITSMASSNAHMEN .............................................................59

6.1 Erzeugung und Installation von Schlüsselpaaren.....................................................59

6.1.1 Erzeugung von Schlüsselpaaren .......................................................................59

6.1.2 Lieferung privater Schlüssel an Zertifikatsnehmer .............................................59

6.1.3 Lieferung öffentlicher Schlüssel an Zertifikatsherausgeber ................................59

6.1.4 Lieferung öffentlicher CA-Schlüssel an Zertifikatsnutzer ....................................59

6.1.5 Schlüssellängen ................................................................................................59

6.1.6 Festlegung der Parameter öffentlicher Schlüssel und Qualitätssicherung .........60

6.1.7 Schlüsselverwendungen ...................................................................................60

6.2 Schutz des privaten Schlüssels und Anforderungen an kryptographische

Module ..............................................................................................................................60

6.2.1 Standards und Sicherheitsmaßnahmen für kryptographische Module ...............60

6.2.2 Mehrpersonen-Zugriffsicherung auf private Schlüssel .......................................60

6.2.3 Hinterlegung privater Schlüssel .........................................................................60

6.2.4 Sicherung privater Schlüssel (Backup) ..............................................................61

6.2.5 Archivierung privater Schlüssel .........................................................................61

6.2.6 Transfer privater Schlüssel in oder aus kryptographischen Modulen .................61

6.2.7 Speicherung privater Schlüssel in kryptographischen Modulen .........................61

6.2.8 Aktivierung privater Schlüssel ...........................................................................62

6.2.9 Deaktivierung privater Schlüssel .......................................................................62

6.2.10 Zerstörung privater Schlüssel .........................................................................62

6.2.11 Bewertung kryptographischer Module ............................................................62

6.3 Andere Aspekte des Managements von Schlüsselpaaren .......................................63

6.3.1 Archivierung öffentlicher Schlüssel ....................................................................63

6.3.2 Gültigkeitsperioden von Zertifikaten und Schlüsselpaaren ................................63

6.4 Aktivierungsdaten ....................................................................................................63

6.4.1 Erzeugung und Installation von Aktivierungsdaten ............................................63

6.4.2 Schutz von Aktivierungsdaten ...........................................................................63


6.4.3 Andere Aspekte von Aktivierungsdaten .............................................................64

6.5 Sicherheitsmaßnahmen für IT-Systeme ...................................................................64

6.5.1 Spezifische technische Sicherheitsanforderungen für IT-Systeme ....................64

6.5.2 Beurteilung der IT-Systemsicherheit ..................................................................64

6.6 Technische Maßnahmen während des Lebenszyklusses ........................................64

6.6.1 Sicherheitsmaßnahmen bei der Systementwicklung .........................................64

6.6.2 Sicherheitsmaßnahmen beim Systemmanagement ..........................................65

6.6.3 Sicherheitsmaßnahmen während des Lebenszyklusses ...................................65

6.7 Sicherheitsmaßnahmen für Netze............................................................................65

6.8 Zeitstempel ..............................................................................................................65

7 PROFILE VON ZERTIFIKATEN, SPERRLISTEN UND OCSP ......................................66

7.1 Zertifikatsprofile .......................................................................................................66

7.1.1 Versionsnummern .............................................................................................66

7.1.2 Zertifikatserweiterungen ....................................................................................66

7.1.3 Algorithmen OIDs ..............................................................................................67

7.1.4 Namensformate.................................................................................................67

7.1.5 Namensbeschränkungen ..................................................................................67

7.1.6 OIDs der Zertifikatsrichtlinien ............................................................................67

7.1.7 Nutzung der Erweiterung „PolicyConstraints” ....................................................67

7.1.8 Syntax und Semantik der Erweiterung „PolicyQualifiers“ ...................................67

7.2 Sperrlistenprofile ......................................................................................................68


7.2.2 Erweiterungen von Sperrlisten und Sperrlisteneinträgen ...................................68

7.3 Profile des Statusabfragedienstes (OCSP) ..............................................................68


7.3.2 OCSP Erweiterungen ........................................................................................69

8 COMPLIANCE-AUDITS UND ANDERE BEWERTUNGEN ...........................................70

8.1 Häufigkeit und Bedingungen für Audits ....................................................................70

8.2 Identität/Qualifikation des Prüfers ............................................................................70


8.3 Stellung des Prüfers zum Bewertungsgegenstand ...................................................70

8.4 Durch Prüfung abzudeckende Themen ...................................................................70

8.5 Reaktionen auf Unzulänglichkeiten ..........................................................................70

8.6 Information über Bewertungsergebnisse..................................................................70

9 Sonstige finanzielle und rechtliche Angelegenheiten ...............................................71

9.1 Preise ......................................................................................................................71

9.1.1 Preise für Zertifikate oder Zertifikatserneuerungen ............................................71

9.1.2 Preise für den Zugriff auf Zertifikate ..................................................................71

9.1.3 Preise für Sperrungen oder Statusinformationen ...............................................71

9.1.4 Preise für andere Dienstleistungen ...................................................................71

9.1.5 Regelungen zur Kostenrückerstattung ..............................................................71

9.2 Finanzielle Zuständigkeiten .....................................................................................71

9.2.1 Versicherungsdeckung ......................................................................................71

9.2.2 Andere Posten ..................................................................................................71

9.2.3 Versicherung oder Gewährleistung für Endnutzer .............................................71

9.3 Vertraulichkeit von Geschäftsinformationen .............................................................71

9.3.1 Definition von vertraulichen Informationen.........................................................71

9.3.2 Informationen, die nicht vertraulich behandelt werden .......................................72

9.3.3 Zuständigkeiten für den Schutz vertraulicher Informationen ..............................72

9.4 Datenschutz von Personendaten .............................................................................72

9.4.1 Datenschutzkonzept ..........................................................................................72

9.4.2 Als persönlich behandelte Daten .......................................................................72

9.4.3 Daten, die nicht als persönlich behandelt werden ..............................................72

9.4.4 Zuständigkeiten für den Datenschutz ................................................................72

9.4.5 Hinweis und Einwilligung zur Nutzung persönlicher Daten ................................72

9.4.6 Auskunft gemäß rechtlicher oder staatlicher Vorschriften ..................................73

9.4.7 Andere Bedingungen für Auskünfte ...................................................................73

9.5 Urheberrechte .........................................................................................................73

9.6 Zusicherungen und Garantien .................................................................................73


9.6.1 Zusicherungen und Garantien einer CA ............................................................73

9.6.2 Zusicherungen und Garantien einer RA ............................................................73

9.6.3 Zusicherungen und Garantien der Zertifikatsnehmer .........................................73

9.6.4 Zusicherungen und Garantien der Zertifikatsnutzer ...........................................73

9.6.5 Zusicherungen und Garantien anderer Teilnehmer ...........................................74

9.7 Haftungsausschlüsse...............................................................................................74

9.8 Haftungsbeschränkungen ........................................................................................74

9.9 Schadensersatz .......................................................................................................74

9.10 Gültigkeitsdauer des CPS und Beendigung der Gültigkeit ....................................74

9.11 Individuelle Mitteilungen und Absprachen mit Teilnehmern ..................................74

9.12 Änderungen des CPS ...........................................................................................74

9.13 Verfahren zur Schlichtung von Streitfällen ............................................................74

9.14 Zugrundeliegendes Recht ....................................................................................75

9.15 Einhaltung geltenden Rechts ................................................................................75

9.16 Sonstige Bestimmungen .......................................................................................75

9.16.1 Vollständigkeitserklärung ...............................................................................75

9.16.2 Abgrenzungen ...............................................................................................75

9.16.3 Salvatorische Klausel .....................................................................................75

9.16.4 Vollstreckung (Anwaltsgebühren und Rechtsmittelverzicht) ...........................75

9.16.5 Höhere Gewalt ...............................................................................................75

9.17 Andere Bestimmungen .........................................................................................75

10 ANHANG ....................................................................................................................76

10.1 Quellenverzeichnis ...............................................................................................76

10.2 Anlagen ................................................................................................................76

10.3 Verantwortlichkeiten .............................................................................................77


Vorbemerkungen: Wenn dieses Dokument in einer Sprache geschrieben ist, in der Funktionsbezeichnungen für

männliche, weibliche und diverse Personen unterschiedlich sind, dann schließen die

verwendeten Bezeichnungen Personen aller Geschlechter mit ein.

In diesem Dokument werden die Referenzen auf Quellen, Anlagen oder verantwortliche

Stellen in eckigen Klammern dargestellt. Eine Auflistung der mit [n] (Beispiel: [1])

gekennzeichneten Quellen findet sich in Abschnitt 10.1, die mit [An] (Beispiel: [A1])

gekennzeichnete Anlagen sind in Abschnitt 10.2 und die mit [Vn] (Beispiel: [V1])

gekennzeichneten Verantwortlichkeiten sind in Abschnitt 10.3 benannt.


1 EINLEITUNG

1.1 Überblick

Im Gegensatz zur Volkswagen Group Product PKI ist der Zweck der Volkswagen Group

Product Legacy PKI, Zertifikate für Produkt-Komponenten zu erstellen, die keine Online-

Verbindung aufbauen (können).

Dieses CP-Dokument beschreibt die Anforderungen an den Betrieb der Root-CA. Diese CP

kann auch für weitere Zertifizierungsstellen (CAs) der Product PKI gelten. Eine Aufstellung

der untergeordneten Zertifizierungsstellen, für deren Betrieb diese CP angewendet werden

muss, ist in Anlage [A1] aufgeführt. Eine Ausweitung oder Reduzierung der Anwendung

dieser CP auf weitere bzw. weniger CA-Typen darf nur von [V3] freigegeben werden.

Für andere CAs (direkt oder indirekt) unter dieser Root-CA müssen separate CP-

Dokumente erstellt werden. Eine Sub-CA darf nur dann von einer CA, für deren Betrieb

diese CP angewendet wird (siehe Abschnitt 1.3.1), ein digitales Zertifikat erhalten, wenn das

CP-Dokument von [V4] akzeptiert wird.

Anforderungen an CP-Dokumente von Sub-CAs, deren Zertifikate unter Anwendung dieser

CP signiert werden dürfen:

• Eine Sub-CA-CP darf keine Aussagen enthalten, die den Anforderungen dieser Root-

CP widersprechen, es sind ausschließlich verschärfende Anforderungen erlaubt.

• Zertifikate unter den Sub-CAs dürfen nur von Entitäten (= RA-Officer) bei den Sub-

CAs angefordert werden, wenn diese Entitäten vorher hinreichend authentifiziert

wurden. Dabei soll die Authentifikation anhand von Zertifikaten der Volkswagen PKI

erfolgen. Andere Authentifikationsverfahren dürfen nur verwendet werden, wenn sie

von der für die Volkswagen Product PKI verantwortlichen Stelle (siehe [V4])

freigegeben wurden.

• Zertifikate für Sub-CAs dürfen nur gemeinsam von zwei entsprechend

authentifizierten Entitäten (Security-Officer) eingerichtet werden, wenn dies zuvor

durch das Coordination Center Product PKI genehmigt wurde.

1.1.1 Zertifikatstypen

Diese CA nutzt oder erstellt nur Zertifikate mit dem Format X.509v3 oder Sperrlisten mit dem

Format X.509v2 gemäß dem RFC 5280 der Network Working Group.


Bei den Zertifikaten werden folgende Typen unterschieden:

• CA-Zertifikate Bei diesen Zertifikaten ist in der Erweiterung „Basic Constraints“

das Flag „CA=true“ gesetzt.

• End-Zertifikate Bei diesen Zertifikaten ist in der Erweiterung „Basic Constraints“

das Flag „CA=false“ gesetzt. Bei End-Zertifikaten werden

wiederum folgende Typen unterschieden:

o Betriebs-End-Zertifikate, die für den Betrieb der jeweiligen

CA benötigt werden, müssen von dem Zertifikat der CA

signiert sein, für deren Betrieb sie verwendet werden

sollen.

Anlage [A1] enthält eine Aufstellung der Betriebs-End-

Zertifikate, die ausgegeben werden dürfen.

o Produkt-End Zertifikate, die für Produkt-Entitäten im

Rahmen der Use-Cases ausgegeben werden, für die die

jeweilige CA eingerichtet ist.

Produkt-End-Zertifikate dürfen nur von CA-Typen der

untersten CA-Ebene erzeugt werden.

Welche Produkt-End-Zertifikate ausgestellt werden sollen,

muss im jeweiligen CP festgehalten sein.

1.1.2 Struktur des Dokuments

Die Struktur dieses Dokuments orientiert sich am Abschnitt 4 „Contents of a Set of

Provisions“ des RFC 3647 und enthält u.a. die darin aufgeführten Gliederungspunkte. Wenn

im RFC 3647 innerhalb eines Abschnitts mehrere Themen aufgezählt sind, sind in dieser CP

in der Regel für solche Themen Unterabschnittsnummern vergeben worden.

Zusätzlich wurde ein Abschnitt 10 als Anhang eingefügt.

1.1.3 Konventionen / Nomenklatur

Bei der Formulierung einzelner Regelungen dieses Dokuments werden bei Bedarf die

Begriffe „muss“, „darf nur“, „darf nicht“, „darf kein“ „soll“, „soll nicht“, „kann“ und „braucht nicht“ in Fettschrift in den jeweiligen Beugungsformen verwendet. Deren Bedeutung ist wie

folgt geregelt:


• „muss“ / „darf nur“ / „darf nicht“ / „darf kein“ „darf erst, wenn“ / „darf…weder…noch“: verbindliche Vorgabe

• „soll“ / „soll nicht“ / „soll nur“: Vorgabe, Nichteinhaltung nur in

begründeten Ausnahmefällen

• „kann“ / „braucht nicht“: optional

1.2 Dokumentenname und Identifikation

Dieses Dokument ist folgendermaßen identifiziert:

• Dokumentenname: Volkswagen Group Product Legacy PKI:

Certificate Policy (CP) für die Legay Root-CA

der Produktiv-PKI für Serienkomponenten

• Object Identifier (OID) ohne Version: 1.3.6.1.4.1.3210.8009.20.2.1.4.1.0.1.2

• Version: 1.19

1.3 PKI Teilnehmer

PKI Teilnehmer sind Zertifizierungsstellen, Registrierungsstellen und Zertifikatsnehmer der

Volkswagen Group und andere Teilnehmer.

1.3.1 Zertifizierungsstellen (CA)

Eine grafische Übersicht der PKI-Struktur findet sich in Anlage [A1].

1.3.1.1 ROOT-CA

Die Volkswagen Group Legacy Product PKI basiert auf einer dreistufigen Hierarchie.

Die Volkswagen Group Legacy Root-CA führt das Signieren, Ausstellen und Widerrufen von

Intermediate CAs durch. Die Volkswagen Group Legacy Root-CA stellt ausschließlich CA-

Zertifikate und Betriebs-End-Zertifikate aus. Die Volkswagen Group Legacy Root-CA signiert

außerdem die Sperrlisten der Root-CA. Zu den Betriebs-End-Zertifikaten zählen auch End-

Zertifikate, die Container signieren die weitere Product PKI Root - Zertifikate im Rahmen

eines Tauschs, einer Erneuerung der Root-CA zur Einbringung in Endgeräten absichern.

1.3.1.2 Intermediate CAs


Die Intermediate CAs sind Teil des UseCase innerhalb der Product PKI und stellen auf Level

1 unterhalb der Root-CA das Bindeglied zwischen Root-CA und Issuing CA dar.

Intermediate CAs stellen CA-Zertifikate und Betriebs-End-Zertifikate aus, die für den Betrieb

der CA erforderlich sind und signieren die zu der CA gehörenden Sperrlisten.

1.3.1.3 Issuing CAs

Die auf Level 2 unterhalb der Intermediate CAs angesiedelten Issuing CAs der Volkswagen

Group Product PKI erstellen End-Zertifikate für Zertifikatsnehmer und verwalten und

widerrufen im Bedarfsfall End-Zertifikate.

Zertifizierungsstellen, für die die Zertifikate unter Anwendung dieser CP signiert werden

können, werden in der Anlage [A1] aufgeführt.

Ein Hinzufügen oder Reduzieren von Zertifizierungsstellen, für die die Zertifikate unter

Anwendung dieser CP signiert werden, darf nur nach Freigabe von [V3] erfolgen.

Zur Anwendung dieser CP für den Betrieb dieser Zertifizierungsstellen siehe Abschnitt 1.1.

1.3.2 Registrierungsstellen (RA)

Anträge auf Erstellung oder Sperrung von Zertifikaten (siehe Abschnitt 1.3.3) dürfen nur über eine RA der Volkswagen Group Product PKI an eine CA übergeben werden.

Für jede CA, auf deren Betrieb diese CP angewendet wird (siehe Abschnitt 1.1) muss im

zugehörigen CPS festgelegt werden, welche RA(s) zur Übergabe der Anträge genutzt

werden darf/dürfen.

Die Registrierungsstelle ist verantwortlich für die Identifikation und Authentifikation von

Antragsstellern.

Diese Verantwortung beinhaltet unter anderem:

- Bereitstellung einer Infrastruktur und von Prozessen zur Entgegennahme von

Zertifikatsanträgen von Antragsstellern

- Identifikation und Authentifikation von Zertifikats-Antragsstellern und

Zertifikatsinhabern

- Annahme oder Zurückweisung von Zertifikatsanträgen

- Bereitstellung einer Infrastruktur und von Prozessen, um dem Antragssteller das

ausgestellte Zertifikat zu übermitteln

- Prüfung von Sperranträgen


- Annahme oder Zurückweisung von Sperranträgen

- Identifikation und Authentifizierung von Anträgen auf Folgezertifikate

1.3.3 Zertifikatsinhaber

Zertifikatsinhaber ist immer die Volkswagen Group als juristische Person, die die End-

Zertifikate beantragt und besitzt. Verantwortlich für den Schlüssel und den Inhalt des End-

Zertifikats ist der Zertifikatsnehmer. Die Volkswagen Group delegiert jedoch Rechte an

bestimmte Personen und Funktionen, die dann im Auftrag der Volkswagen Group

(Zertifikatsinhaber) handeln. Beispiele für solche Personen und Funktionen sind

Administratoren oder Mitarbeiter der Konzernmarken. Beispiele für Dritte sind Dienstleister,

mit denen der Konzern oder die Marke ein Vertragsverhältnis unterhalten und welche vom

CCPP hinsichtlich der Wahrnehmung der Aufgaben geprüft und bestätigt wurden.

1.3.4 Zertifikatsnehmer

Der Zertifikatsnehmer ist die individuelle Entität, die durch den privaten Schlüssel

authentifiziert wird und Kontrolle über ihre Verwendung hat.

Der Zertifikatsnehmer

- wird in dem Subject-Feld des Zertifikats genannt oder kann daran identifiziert werden,

- besitzt den privaten Schlüssel, der zu dem öffentlichen Schlüssel gehört, der in

diesem Zertifikat aufgeführt ist.

In der Verantwortung des Zertifikatsnehmers liegen:

- alle zumutbaren und notwendigen Vorkehrungen zu treffen, um den Verlust, die

Offenlegung, die Änderung oder die unbefugte Verwendung des privaten

Schlüssels des Zertifikatsnehmers oder der Zugangsdaten, die den Zugriff

ermöglichen, zu verhindern

- Zertifikate nur für definierte Zwecke innerhalb des UseCases, für die von der CA

unterstützten Anwendungen und für die erforderliche Dauer zu verwenden

- nur Schlüsselpaare verwenden, die an gültige Zertifikate gebunden sind

- die Nutzung des privaten Schlüssels nach Sperrung oder Ablauf des Zertifikats

einstellen

Zu den Aufgaben des Zertifikatsnehmers gehören:


- vollständige, genaue und wahrheitsgemäße Informationen in einem Zertifikatsantrag

bereitstellen

- die Sperrung des Zertifikats des Zertifikatsnehmers anfordern, wenn das Zertifikat

falsche Informationen enthält oder der private Schlüssel des Zertifikatsnehmers oder

die den Zugriff kontrollierenden Zugangsdaten verloren gegangen sind oder wenn der

Zertifikatsnehmer Grund zu der Annahme hat, dass der private Schlüssel von einer

anderen Person erlangt oder anderweitig kompromittiert wurde

- Empfangsbestätigung nach Zertifikatszustellung oder Zustimmung zu den Pflichten

des Zertifikatsnehmers

Pflichten der Zertifikatsnehmer

Zertifikatsnehmer müssen

• die für die Nutzung notwendigen CA-Zertifikate und Gültigkeitsinformationen aus den

bereitgestellten Verzeichnissen (siehe Abschnitt 2.1) oder von den bereitgestellten

Diensten (siehe Abschnitt 4.10.1) abrufen.

• neue CA-Zertifikate, unter denen für die Nutzung relevante Zertifikate ausgegeben

werden, als vertrauenswürdig übernehmen, nachdem eine Gültigkeitsprüfung der CA-

Zertifikate durch die Nutzer erfolgreich durchgeführt wurde. Das Verfahren der

Gültigkeitsprüfung ist in Abschnitt 5.6 beschrieben.

• , sofern technisch möglich, Sperrinformationen von den im Zertifikat genannten

(Dienst-) Adressen (CDP) laden und verarbeiten.

• , wenn sie Sperrlisten zur Gültigkeitsprüfung verwenden, spätestens alle 7 Tage

erneut Sperrlisten laden.

1.3.5 Zertifikatsnutzer

Ein „Zertifikatsnutzer“ ist ein PKI-Teilnehmer, der ein Zertifikat verwendet, um den

öffentlichen Schlüssel des Zertifikatsnehmers zu erhalten und in der Lage ist, sich auf die

Zusicherungen im Zertifikat zu verlassen.

Zu den Pflichten der Zertifikatsnutzer gehören:

- Kryptografische Operationen ordnungsgemäß durchzuführen: Verifizieren von

digitalen Signaturen durch Bezugnahme auf den öffentlichen Schlüssel des

Zertifikatsnehmers, der in einem gültigen Zertifikat aufgeführt ist, und Verifizieren, ob


es einen zulässigen Zertifikatspfad (Pfeilpfadprüfung) zu einer vertrauenswürdigen

CA gibt

- Überprüfen des Status von Zertifikaten, bevor ein Vertrauensstatus dazu aufgebaut

wird, einschließlich des Sperrstatus in der Zertifikatssperrliste (CRL)

- ggf. Zustimmung zu den Bedingungen einer vertraglichen Vereinbarung, die

Voraussetzung ist, um sich auf das Zertifikat zu stützen

Zertifikatsnutzer sind alle Dienste, die Entitäten anhand von Zertifikaten identifizieren oder

authentifizieren, die im Rahmen der Volkswagen Group Product PKI erstellt wurden. Das

können sowohl Volkswagen Group-interne als auch –externe Dienste sein.

1.4 Verwendung von Zertifikaten

1.4.1 Erlaubte Verwendung von Zertifikaten

Die unter Anwendung dieser CP erstellten Zertifikate (siehe Abschnitt 1.3.3) dürfen von den

Zertifikatsnutzern nur im Rahmen der in den Zertifikaten eingetragenen Zertifikatsverwen-

dungen (keyUsage und extended KeyUsage) genutzt werden.

Die Zertifikate der Volkswagen Group Product PKI dürfen nur im Rahmen der zugelassenen

UseCases (siehe Namenskonvention) verwendet werden.

1.4.2 Untersagte Verwendung von Zertifikaten

Zertifikate, die unter Anwendung dieser CP erstellt werden, dürfen nicht für andere Zwecke

verwendet werden als in Abschnitt 1.4.1 beschrieben.

1.5 Verwaltung der Richtlinie

1.5.1 Änderungsmanagement

Änderungen an dieser CP dürfen nur von [V1] freigegeben werden.

1.5.2 Ansprechpartner

Ansprechpartner für dieses Dokument ist die Stelle, die für die Volkswagen Group Product

PKI verantwortlich ist (siehe [V4]).


1.5.3 Eignungsprüfer zur Feststellung der Regelkonformität eines CPS

Für die Prüfung der Regelkonformität eines CPS zu dieser CP ist [V2] verantwortlich.

1.5.4 Verfahren zur Freigabe eines CPS

Ein CPS zu dieser CP darf nur von [V2] freigegeben werden.

Ohne ein zugehöriges freigegebenes CPS darf eine CA nicht betrieben werden.

1.6 Begriffe und Akronyme

AIA Authority Information Access: Attribut in einem Zertifikat, enthält

Informationen zum Zugriff auf Zertifizierungsstellen-

Informationen oder OCSP-Service-Adressen.

Antragsteller siehe Zertifikatsantragsteller

BasicContraints Attribut in einem Zertifikat, welches Einschränkungen innerhalb

einer PKI festlegt. Beispielsweise die Länge des

Zertifizierungspfades.

Betriebs-End-Zertifikate End-Zertifikate für Entitäten, die für den Betrieb der jeweiligen

CA benötigt werden (z.B. Signierer für OCSP-Antworten)

BSI Bundesamt für Sicherheit in der Informationstechnik

CA zu einer CRL Eine CRL gehört dann zu einer CA, wenn Zertifikate, die von

der CA erstellt werden, in der CRL auftreten können. Eine CRL

kann auch zu mehreren CAs gehören.

CA-Typ Der Typ gibt den Verwendungszweck der CA an (z.B. „ROOT“).

Die Typ-Bezeichnung besteht aus 4 Zeichen. Für den CA-

spezifischen Teil des CA-Namens werden die Zeichen „CA“

angehängt (z.B. „ROOTCA“). Die Typ-Bezeichnung ist

Bestandteil des CN des CA-Zertifikats (siehe Abschnitt 3.1.1).

CCPP Coordination Center Product PKI: Das Coordination Center ist

ein markenübergreifendes virtuelles Team und die

verantwortliche Stelle [V3], welche themenspezifische

Entscheidungen produktnaher PKI- und Zertifikat-Themen


herbeiführt, selbst die Entscheidung durchführt oder an

Risikobewertungen beteiligt ist.

CDP CRL Distribution Point: Pfad zu einem Verzeichnis, in dem die

CRL einer Zertifizierungsstelle enthalten ist.

CERT Computer Emergency Response Team

Certificate Authority (CA) Instanz, die Zertifikate an weitere Zertifikatsnehmer ausstellen

kann.

Certificate Policy (CP) Richtlinie, die Anforderungen an die Funktionsweise einer PKI

oder CA formuliert.

Common Name (CN) Komponente des Distinguished Name (DN).

CPS Certification Practice Statement: Beschreibung der

Maßnahmen, um einer CP zu genügen.

CRL Certificate Revocation List: Liste der Zertifikate, die von der

ausgebenden CA (inzwischen) gesperrt wurden. In einem

Zertifikat ist der CRL-Name angegeben, in dem es auftreten

würde, wenn es gesperrt wurde.

Eine CRL gehört zu der CA bzw. ist die CRL der CA, die die

Zertifikate signiert hat, die in der CRL enthalten sein können.

Cross-Zertifikat Ein Zertifikat, das bei einer Cross-Zertifizierung erstellt wird.

Cross-Zertifizierung Vorgang, bei dem zu einem bestehenden Zertifikat ein weiteres

Zertifikat für denselben Zertifikatsnamen und denselben

öffentlichen Schlüssel von einer anderen CA als der des

ursprünglichen Zertifikats erstellt wird.

CSB Car Security Board: Dies ist ein Gremium, welches

Entscheidungen bei Sicherheitsvorfällen trifft. Dieses Gremium

stimmt diese Entscheidungen auch markenübergreifend ab.

CSI Car Security Incident Team: Dies ist das Team welches

Sicherheitsvorfälle entgegennimmt, die erforderlichen

Fachbereiche einbezieht und auf das Car Security Board für die

Klärung zugeht.


Distinguished Name (DN) Ein aus mehreren Bestandteilen bestehenden Bezeichner, der

in Zertifikaten die ausstellende CA und den Zertifikatsinhaber

eindeutig beschreibt. Der DN wird im Standard X.501 definiert.

End-Zertifikate Alle Zertifikate der PKI, die keine CA repräsentieren.

FIPS Federal Information Processing Standard: Bezeichnung für

öffentlich bekanntgegebene Standards der USA.

FIPS-140: Sicherheitsanforderungen für kryptographische

Module

GID Global Identifier: Eindeutige ID eines Eintrags im VCD der

Volkswagen AG, kann auch in Zertifikaten verwendet werden.

Hardware Security Module IT-System zur Erzeugung und ggf. Verwahrung

kryptographischen Schlüsselmaterials.

http hypertext transfer protocol: Übertragungsprotokoll für Daten

über ein Netzwerk.

HSM siehe „Hardware Security Module“

ldap lightweight data access protocol: Übertragungsprotokoll für

Anfragen an Verzeichnisdienste bzw. deren Antworten.

KeyUsage Eintrag in einem Zertifikat. Gibt an, für welchen Nutzungszweck

ein Schlüsselpaar zertifiziert wurde bzw. verwendet werden

darf.

KSU Klassifizierungssystematik für Unterlagen: Regelung der

Volkswagen AG, wie Unterlagen in die Klassen „öffentlich“,

„intern“, „vertraulich“ und „geheim“ eingeteilt werden und wie die

Unterlagenklassen jeweils zu behandeln sind.

n-von-m-Prinzip Die Berechtigungen für eine Funktion oder ein Geheimnis wird

so auf m Stellen verteilt, dass n davon notwendig sind die

Funktion durchzuführen bzw. das Geheimnis komplett zu

erstellen. Dabei gilt 0 < n ≤ m.

OCSP Online Certificate Status Protocol: Ein alternatives Verfahren

zur Sperrstatusprüfung von Zertifikaten. Hierbei handelt es sich

um ein Client-Server-Protokoll, bei dem nur geringe

http://de.wikipedia.org/wiki/Standard


Datenmengen ausgetauscht werden. OCSP-Nachrichten

müssen von einer vertrauenswürdigen Entität signiert sein.

OCSP-Stapling Bezeichnet ein auf OCSP basiertes Verfahren (siehe auch RFC

6066), bei welchem der angefragte Server seinen Sperrstatus

initial beim Verbindungsaufbau mitteilt, sofern der Client diesen

Status anfragt. Dieses Verfahren verringert den

Kommunikationsaufwand zwischen Clients und OCSP-

Respondern deutlich.

OE Organisationseinheit eines Unternehmens oder einer Behörde,

die für bestimmte Funktionen Aufgaben übernehmen kann.

PathLengthConstraint Attribut in CA-Zertifikaten, das die maximale Anzahl erlaubter

CA-Hierachie-Ebenen unterhalb einer CA definiert.

PKI Public Key Infrastructure: bezeichnet ein System, das digitale

Zertifikate ausstellen, verteilen oder sperren kann und

Gültigkeitsinformationen für ausgestellte Zertifikate bereitstellen

kann.

PKI-Funktionsstelle Stellen, die dafür verantwortlich sind, Änderungen an

Zertifikaten (z.B. Erstellen, Sperren oder Wiederfreigeben von

Zertifikaten), an Konfigurationen eines PKI-Systems (z.B.

Parameter für Zertifikatserstellungen, Logging-Level oder

Verteilungsverfahren) oder an Berechtigungen für PKI-

Administrationsarbeiten vorzunehmen

Produkt-End-Zertifikate End-Zertifikate, die für Entitäten ausgestellt werden, die im

Rahmen eines Use-Cases Zertifikate benötigen.

Public Key Infrastructure siehe „PKI”

RA siehe „Registration Authority“

RA-Officer Entität, die in einer RA Anforderungen (z.B. Zertifikats- oder

Sperranforderungen) an den jeweiligen CA-Dienst eingibt. RA-

Officer können Personen sein oder – bei automatisierten RAs –

Prozesse mit eigener Identität.

Registrierungsstelle siehe „Registration Authority“

http://de.wikipedia.org/wiki/Digitales_Zertifikat

http://de.wikipedia.org/wiki/Digitales_Zertifikat


Registration Authority Funktionsstelle, die

• die initiale Identifizierung von Entitäten anhand bestimmter

Merkmale vornimmt

• Anforderungen zur Erstellung oder Sperrung von

Zertifikaten entgegennimmt und an die jeweiligen CAs

weiterleitet

• Zertifikate nach ihrer Erstellung an den Antragsteller

übergibt bzw. den Antragsteller über die

Zertifikatserzeugung informiert.

Re-Keying Erzeugung eines neuen Zertifikats mit neuen Schlüsseln für

eine Entität, die bereits ein Zertifikat besitzt.

Rezertifizierung siehe Zertifikatserneuerung

RFC Requests for Comments: Bitte um Kommentierung

Folge von Dokumenten mit technischen Spezifikationen,

einzelne RFCs bzw. deren Inhalte können sich durch

allgemeine Akzeptanz zu Standards entwickeln.

Root-CA Oberster Vertrauensknoten im CA-Baum einer PKI. Das

Zertifikat der Root-CA ist durch den eigenen privaten Schlüssel

signiert (self-signed).

Schlüsselträger Komponente, auf dem ein Zertifikat und auch der zugehörige

geheime Schlüssel gespeichert sind. Der Schlüsselträger wird

dem Zertifikatsinhaber übergeben. Schlüsselträger können

Dateien (Soft-Token, Soft-PSE) oder spezielle Hardware (z.B.

Smart Cards) sein.

Schlüsselverantwortlicher Person, die für die korrekte Nutzung und Unversehrtheit des

privaten Schlüssels (eines Zertifikats) verantwortlich ist.

Security Officer Verantwortliche Rolle zur Umsetzung von

Sicherheitsmaßnahmen innerhalb einer IT-Infrastruktur z.B.

einer PKI.

SO siehe „Security Officer”


Soft-PSE Software Personal Security Environment: Eine Datei, die einen

privaten Schlüssel sowie das zugehörige Zertifikat und den

öffentlichen Schlüssel enthält.

Sperrliste siehe „CRL“

Sub-CA CA, die einer anderen CA untergeordnet ist. Das Zertifikat einer

Sub-CA ist von der übergeordneten CA signiert.

Uniform Resource Locator Eindeutige Angabe für einen Zugriffspunkt für eine Ressource,

die sich aus der Zugriffsmethode (Protokoll) und der Server-

Adresse (üblicherweise des DNS-Namens) des Systems

zusammensetzt.

URL siehe Uniform Resource Locator

VCD Volkswagen Corporate Directory: zentrales Daten-Repository

des Volkswagen Konzerns für definierte personenbezogene

und systembezogene Daten.

Wurzelzertifizierungsstelle siehe „Root-CA“

Zertifikatsantragssteller Entität, die für sich oder einen Dritten ein Zertifikat bei einer RA

beantragt. Der Antragsteller kann je nach Policy eine Person,

eine OE oder ein Dienst/Prozess sein.

Zertifikatserneuerung Erstellung eines neuen Zertifikats für einen Zertifikatsinhaber

unter Nutzung desselben Schlüsselpaars wie in einem bereits

vorhandenen Zertifikat desselben Zertifikatsinhabers.

Zertifikatsname Name der Entität, auf die ein Zertifikat ausgestellt wird. Der

Name steht im Subject-Feld (Microsoft-Übersetzung:

Antragsteller-Feld) oder in der Subject Alternative Name-

Extension (alternativer Antragsteller-Erweiterung) des Zertifikats

Zertifikatsinhaber Entität, für die ein Zertifikat ausgestellt wird. Dabei kann es sich

z. B. um eine Person, eine Funktions- oder

Organisationseinheit, eine CA oder einen technischen Dienst

handeln.

Außer bei Personenzertifikaten sind in der Regel


Zertifikatsinhaber und Zertifikatsantragsteller unterschiedliche

Entitäten.

Zertifikatsnutzer Eine Stelle oder Dienst, die bzw. der anhand von Zertifikaten

die Identität von Zertifikatsnehmern überprüft.

Zertifizierungsstelle siehe „CA“


2 VERANTWORTLICHKEITEN FÜR VERZEICHNISSE UND VERÖFFENTLICHUNGEN

2.1 Verzeichnisse

Für die Veröffentlichung von Zertifikaten und Sperrlisten der Volkswagen Product PKI

werden zentrale Verzeichnisdienste bereitgestellt.

Diese Verzeichnisdienste müssen für alle Zertifikatsnutzer aufrufbar sein.

Das zentrale Verzeichnis für Sperrinformationen ist unter

http://crl.vwg-connect.com/

erreichbar, siehe dazu auch Abschnitt 4.9 im CPS zu dieser CP.

Das zentrale Verzeichnis zur Veröffentlichung von CA-Zertifikaten ist unter

https://group-wiki.wob.vw.vwg/wikis/display/VWGPPKI/Aktuelle+Zertifikate

erreichbar.

Zur Abrufpflicht von Informationen aus Verzeichnissen siehe Abschnitt 0.

2.2 Veröffentlichungen von Informationen zur Zertifikatserstellung

Zertifikate von CAs, die unter Anwendung dieser CP (siehe Abschnitt 1.3.1) erstellt werden,

müssen über die zentralen Verzeichnisdienste der Volkswagen Product PKI (siehe Abschnitt

2.1) veröffentlicht werden.

End-Zertifikate, die unter Anwendung dieser CP (siehe Abschnitt 1.3.1) erstellt werden,

können über die zentralen Verzeichnisdienste der Volkswagen Group Product PKI (siehe

Abschnitt 2.1) veröffentlicht werden.

2.3 Zeitpunkt und Häufigkeit von Veröffentlichungen

Zertifikate und Sperrlisten müssen zeitnah nach der Erstellung veröffentlicht werden.

Die Zertifikate dürfen frühestens 4 Jahren nach Ablauf ihrer Gültigkeitsendetermine aus den

Verzeichnissen gelöscht werden.

http://crl.vwg-connect.com/


2.4 Zugriffskontrolle auf Verzeichnisse

Lesezugriff auf die Zertifikate in den Verzeichnissen braucht für Nutzer innerhalb des

Volkswagen Konzerns nicht beschränkt zu werden. Alle Nutzer von Zertifikaten, die unter

Anwendung dieser CP erstellt wurden, müssen zum Lesen berechtigt sein.

Das Recht, die Liste der veröffentlichten Zertifikate oder Sperrlisten zu verändern, darf nur an Entitäten vergeben werden, die für

• die ordnungsgemäße Bereitstellung des jeweiligen Verzeichnisses

oder

• die ordnungsgemäße Bereitstellung der Zertifikate bzw. Sperrlisten

verantwortlich sind.


3 IDENTIFIKATION UND AUTHENTIFIZIERUNG

3.1 Namensregeln

3.1.1 Namensformen

• Zertifikate für CAs, die unter Anwendung dieser CP (siehe Abschnitt 1.3.1) erstellt

werden, müssen folgende Namen tragen:

VWG_PRLGC_LIVE_PRD_<ca-type>CA_nnn

Dabei gibt <ca-type> den CA-Typ an (z.B. „ROOT“ für die Root-CA selbst) und nnn

eine 3-stellige dezimale Nummer, die den Zertifikatsnamen innerhalb der Zertifikate

desselben CA-Typs eindeutig machen muss.

• Zertifikatsnamen für Betriebs-End-Zertifikate, die unter dieser CP erstellt werden,

müssen den Aufbau

VWG_PRLGC_LIVE_PRD_<ca-type><function>_<number_of_issuing_ca>

haben, dürfen am Ende keinen eigenen numerischen Namensteil, sondern müssen

den der erstellenden CA enthalten und müssen die Anforderungen der

Namenskonvention gemäß Anlage [A2] erfüllen.

Zur Auflistung von zugelassenen Zertifikatsnamen siehe Abschnitt 1.3.3.

3.1.2 Notwendigkeit aussagekräftiger Namen

Die Zertifikate, die unter Anwendung dieser CP erstellt werden, müssen eindeutig die

Funktion des Zertifikatsnehmers erkennen lassen (siehe Abschnitt 3.1.1).

3.1.3 Anonymität bzw. Pseudonymität von Zertifikatsnehmern

Unter Anwendung dieser CP dürfen keine Zertifikate für Personen ausgestellt werden.

3.1.4 Regelungen zur Interpretation verschiedener Namensformen

keine Vorgaben

3.1.5 Eindeutigkeit von Namen

Alle Zertifikate mit demselben Zertifikatsnamen müssen für dieselbe logische Entität

ausgestellt sein. Werden für eine logische Entität mehrere Instanzen betrieben (z.B. zur

Erhöhung der Verfügbarkeit), kann dafür derselbe Zertifikatsname verwendet werden.


Durch den numerischen Bestandteil am Ende des Zertifikatsnamens für CA-Zertifikate darf der Name nur genau einem Zertifikat zugewiesen werden. Für ein Nachfolge-CA-Zertifikat

soll die kleinste bisher unbenutzte natürliche Nummer eingetragen werden (siehe Abschnitt

5.6).

3.1.6 Anerkennung, Authentifizierung und Funktion von Warenzeichen

keine Vorgaben im Rahmen dieser CP

3.2 Identitätsprüfung bei Erstantrag

3.2.1 Nachweis des Besitzes des privaten Schlüssels

Die privaten Schlüssel von CA-Zertifikaten und von Betriebs-End-Zertifikaten müssen

entweder auf einem angeschlossenen HSM gespeichert werden oder aber dürfen nur in

Verbindung mit diesem entschlüsselbar sein, wenn sie nicht direkt im HSM gespeichert

werden.

3.2.2 Authentifizierung von Organisationen

Unter Anwendung dieser CP dürfen keine Zertifikate für Organisationen erstellt werden.

3.2.3 Authentifizierung natürlicher Personen

Unter Anwendung dieser CP dürfen keine Zertifikate für natürliche Personen erstellt

werden.

3.2.4 Nicht überprüfte Teilnehmerangaben natürlicher Personen

siehe Abschnitt 3.2.3

3.2.5 Überprüfung der Berechtigungen

Neue CAs dürfen nur eingeführt werden, wenn das durch [V3] freigegeben wurde. Ein CA-

Zertifikat für einen freigegebenen UseCase darf nur von der Stelle beantragt werden, die für

diese CA verantwortlich ist. Das Coordination Center Product PKI muss eine Liste der

Berechtigten zur Beantragung von CA-Zertifikaten anlegen und pflegen.

CA-Zertifikate, die unter Anwendung dieser CP (siehe Abschnitt 1.3.1) signiert werden,

dürfen nur von mindestens 2 autorisierten Personen nach dem Mehraugen-Prinzip erstellt


werden. Die Autorisierung muss anhand von Zertifikaten erfolgen, deren private Schlüssel

auf PKI-Karten der Volkswagen PKI generiert wurden.

Betriebs-End-Zertifikate dürfen nur von der Stelle beantragt werden, die von der CA für die

jeweilige Diensterbringung beauftragt ist (siehe [V4]).

Betriebs-End-Zertifikate, die unter Anwendung dieser CP signiert werden, sollen soweit

technisch möglich von mindestens 2 autorisierten Personen nach dem Mehraugen-Prinzip

erstellt werden. Die Autorisierung muss anhand von Zertifikaten erfolgen, deren private

Schlüssel auf PKI-Karten der Volkswagen PKI generiert wurden.

Die Überprüfungsverfahren für Berechtigungen zu Produkt-End-Zertifikaten müssen im CP

der jeweiligen ausstellenden CA beschrieben sein.

3.2.6 Kriterien zur Interoperabilität

keine Vorgaben

3.3 Identifizierung und Authentifizierung von Zertifikatsanträgen nach Schlüsselerneuerung

3.3.1 Routinemäßige Zertifizierung neuer Schlüssel

Es gelten dieselben Anforderungen wie in Abschnitt 3.2.5.

3.3.2 Zertifizierung neuer Schlüssel nach einer Sperrung des alten Zertifikats

Es gelten dieselben Anforderungen wie in Abschnitt 3.2.5.

3.4 Identifizierung und Authentifizierung von Sperranträgen

Ein unter Anwendung dieser CP signiertes Zertifikat darf nur gesperrt werden, wenn von

• der verantwortlichen Stelle für die CA [siehe [V4]), von der das Zertifikat signiert ist,

oder

• dem Coordination Center Product PKI oder

• dem Car Security Board

ein Sperrantrag gemäß Anlage 2 des CPS zu dieser CP von zwei berechtigten Personen aus

dem o.g. Kreis digital signiert und an die RA-Stelle der CA gesandt wurde.


Das Coordination Center Product PKI muss eine Liste der Verantwortlichen führen und

pflegen.

Siehe zu diesem Verfahren auch das Sperrkonzept der Volkswagen Group Product PKI [A3].

CA-Zertifikate, die unter Anwendung dieser CP (siehe Abschnitt 1.3.1) signiert wurden,

dürfen nur von mindestens 2 autorisierten Personen nach dem Mehraugen-Prinzip gesperrt

werden.

Betriebs-End-Zertifikate, die unter Anwendung dieser CP signiert wurden, sollen soweit

technisch möglich von mindestens 2 autorisierten Personen nach dem Mehraugen-Prinzip

gesperrt werden.

Die Autorisierung der sperrenden Personen muss anhand von Zertifikaten erfolgen, deren

private Schlüssel auf PKI-Karten der Volkswagen PKI generiert wurden.

Die Anforderungen zur Sperrung von Produkt-End-Zertifikaten müssen im CP der

ausstellenden CA beschrieben sein.


4 ABLAUFORGANISATION (Zertifikats-Lebenszyklus)

4.1 Zertifikatsantrag

Zertifikatsantrag meint hier den tatsächlichen, technischen Antrag, also das Stellen eines

„CSR“ (Certificate Signing Request), dem Antrag auf Signatur eines Zertifikats (unabhängig

davon, ob es sich um ein CA-, Betriebs- oder Produkt-End-Zertifikat handelt).

Über das Erfordernis eines Antrags (z.B. im Hinblick auf die Ausweitung der PKI oder die

Bereitstellung auf bestimmten Märkten) entscheidet das CCPP im Einvernehmen mit den

zuständigen Fachabteilungen. Aus dieser Entscheidung heraus kann das Erfordernis zur

(manuellen oder automatisierten) Antragsstellung erwachsen.

4.1.1 Berechtigung zur Antragsstellung

Anträge für CA-Zertifikate, die unter Anwendung dieser CP erstellt werden (siehe Abschnitt

1.3.1) dürfen nur von den Stellen gestellt werden, die für die jeweilige CA verantwortlich

sind (siehe [V4]).

Anträge für Betriebs-End-Zertifikate dürfen nur dann gestellt werden, wenn die zugehörige

Stelle unter Anwendung dieser CP betrieben wird. Solche Anträge dürfen nur von den

Stellen gestellt werden, die für die Erbringung des Dienstes von der CA beauftragt sind

(siehe [V4]).

Die Berechtigungen zur Beantragung von Produkt-End-Zertifikaten müssen in der CP der

erstellenden CA beschrieben sein.

Siehe auch Abschnitt 3.2.5

4.1.2 Registrierungsprozess und Zuständigkeiten

Ein neue SubCA darf nur nach Freigabe durch [V3] registriert werden (siehe auch Abschnitt

3.2.5).

Benötigte Entitäten für Betriebs-End-Zertifikate sollen im Rahmen der Registrierung des CA-

Typs mit registriert werden.

Der Registrierungsprozess für Produkt-End-Zertifikate muss in der CP beschrieben werden,

die für den Betrieb der ausstellenden CA angewandt wird.


4.2 Verarbeitung des Zertifikatsantrags

4.2.1 Durchführung der Identifizierung und Authentifizierung

Die Namen für Zertifikatsnehmer müssen gemäß 3.1.1 gebildet werden. Bei CA-Zertifikaten

muss die Prüfung durch mindestens 2 autorisierte Personen nach dem Mehraugen-Prinzip

erfolgen.

4.2.2 Annahme oder Ablehnung von Zertifikatsanträgen

Zertifikatsanträge dürfen nur angenommen werden, wenn sie sich auf zugelassene

Zertifikatsnehmer gemäß Abschnitt 1.3.3 beziehen.

Fehlerhafte Anträge, Anträge von Nicht-Berechtigten und sonstige unrichtige

Zertifikatsanträge müssen abgelehnt werden.

4.2.3 Fristen für die Bearbeitung von Zertifikatsanträgen

Die Fristen müssen zwischen dem Antragsteller und der Stelle abgestimmt werden, die für

die erstellende CA verantwortlich ist (siehe [V4]).

4.3 Zertifikatsausstellung

4.3.1 Aktionen der Zertifizierungsstelle (CA) bei der Ausstellung von Zertifikaten

Bei der Ausstellung von Zertifikaten müssen folgende Aktionen durchgeführt werden:

• Prüfung des Zertifikatsantrags

• Erstellung des Zertifikats

• Revisionssichere Protokollierung, welcher Zertifikatsantrag durch wen wann in das

PKI-System eingegeben wurde.

• Veröffentlichung des Zertifikats in einem Konzern-intern zugänglichen Verzeichnis

gemäß Abschnitt 2.2

• Information des Antragstellers über die Zertifikatserstellung

4.3.2 Benachrichtigung des Zertifikatsnehmers über die Ausstellung des Zertifikats

Der Antragsteller muss zeitnah über die Ausstellung des Zertifikats informiert werden.


4.4 Zertifikatsübergabe

4.4.1 Verhalten bei der Annahme/Übergabe eines Zertifikats

Der Antragssteller muss das für ihn ausgestellte Zertifikat wie folgt prüfen:

- Zertifikat entspricht dem beantragten Zertifikat, insbesondere hinsichtlich

o Zertifikatstyp

o Zertifikatslaufzeit

o korrekte Signatur durch die CA

o Gültigkeit der Zertifikatskette

o Inhalt des Zertifikats (Common Name, CDP, OCSP-Adresse, KeyUsages etc.)

wie beantragt bzw. entsprechend der Zertifikatsspezifikation.

Fehlerhaft ausgestellte Zertifikate dürfen nicht akzeptiert oder weiterverarbeitet werden. Im

Fehlerfall ist die CA umgehend zu informieren und ein neuer Antrag (CSR) zu stellen.

4.4.2 Veröffentlichung eines Zertifikates durch die CA

CA-Zertifikate und Betriebs-End-Zertifikate müssen direkt an den Antragsteller übergeben

werden und sollen zudem durch Bereitstellung in einem Verzeichnis, das konzernintern

zugänglich ist, veröffentlicht werden.

Die Anforderungen an den Prozess zur Übergabe von Produkt-End-Zertifikaten müssen in

der CP der ausstellenden CA beschrieben werden.

4.4.3 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines Zertifikats

Es gibt keine Benachrichtigungen über die Ausgabe eines Zertifikats.

4.5 Verwendung des Schlüsselpaars und des Zertifikats

4.5.1 Verwendung des privaten Schlüssels und des Zertifikats durch den Zertifikatsnehmer (Zertifikatsinhaber)

Der Zertifikatsnehmer darf den privaten Schlüssel nur im Rahmen der zugelassenen

Schlüsselverwendungen nutzen.

Ein Zertifikatsnehmer darf seinen privaten Schlüssel weder bewusst noch fahrlässig Dritten

zugänglich machen.

Für CA-Zertifikate und für Betriebs-End-Zertifikate gilt:


• Die Schlüsselerzeugung muss auf Seiten des Zertifikatsnehmers erfolgen, so dass

keine Übertragung des privaten Schlüssels nötig ist.

• Der Zertifikatsnehmer darf den privaten Schlüssel nicht anderen Stellen oder

Personen zur Verfügung stellen.

Für Produkt-End-Zertifikate gilt:

• Die Schlüsselerzeugung soll auf Seiten des Zertifikatsnehmers erfolgen, so dass

keine Übertragung des privaten Schlüssels nötig ist.

• Der Zertifikatsnehmer darf den privaten Schlüssel nicht anderen Stellen oder

Personen zur Verfügung stellen

4.5.2 Verwendung des öffentlichen Schlüssels und des Zertifikats durch den Zertifikatsnutzer

Zertifikate, die unter dieser CP erstellt wurden, dürfen nur für die Verwendungen akzeptiert

werden, die durch die Schlüsselverwendungen im Zertifikat festgelegt sind (siehe auch

Abschnitt 1.4).

4.6 Zertifikatserneuerung

Zum Begriff „Zertifikatserneuerung“ siehe Abschnitt 1.6.

4.6.1 Bedingungen für eine Zertifikatserneuerung

Für die unter Anwendung dieser CP erstellten Zertifikate darf keine Zertifikatserneuerung

erfolgen.

4.6.2 Berechtigung zur Beantragung einer Zertifikatserneuerung


4.6.3 Bearbeitungsprozess eines Antrags auf Zertifikatserneuerung


4.6.4 Benachrichtigung des Zertifikatsnehmers über die Ausgabe eines neuen Zertifikats



4.6.5 Verhalten für die Annahme einer Zertifikatserneuerung


4.6.6 Veröffentlichung der Zertifikatserneuerung durch die CA


4.6.7 Benachrichtigung anderer PKI-Teilnehmer über die Erneuerung des Zertifikats


4.7 Zertifizierung nach Schlüsselerneuerung

4.7.1 Bedingungen für eine Zertifizierung nach Schlüsselerneuerung

Eine Ausstellung eines Zertifikats für denselben Zertifikatsnehmer nach Schlüsselerneuerung

darf nur für End-Zertifikate vorgenommen werden.

Für eine Zertifizierung nach einer Schlüsselerneuerung gelten dieselben Anforderungen wie

bei einer neuen Zertifikatsbeantragung.

4.7.2 Berechtigung zur Schlüsselerneuerung

Es gelten dieselben Anforderungen wie bei Abschnitt 4.1.1

4.7.3 Bearbeitung von Zertifikatsanträgen für Schlüsselerneuerungen

Es gelten dieselben Anforderungen wie bei den Abschnitten 4.2 und 4.3.1

4.7.4 Benachrichtigung des Zertifikatsnehmers über die Ausgabe eines Nachfolgezertifikats


4.7.5 Verhalten für die Annahme von Zertifikaten nach Schlüsselerneuerungen


4.7.6 Veröffentlichung von Zertifikaten nach Schlüsselerneuerungen durch die CA



4.7.7 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines Nachfolgezertifikats


4.8 Zertifikatsänderung

4.8.1 Bedingungen für eine Zertifikatsänderung

Wenn sich Voraussetzungen oder Angaben zu einem bestehenden Zertifikat ändern, muss

ein neues Zertifikat beantragt werden.

4.8.2 Wer darf eine Zertifikatsänderung beantragen?


4.8.3 Bearbeitung eines Antrags auf Zertifikatsänderung

Es gelten dieselben Anforderungen wie bei Abschnitt 4.2

4.8.4 Benachrichtigung des Zertifikatsnehmers über die Ausgabe eines neuen Zertifikats


4.8.5 Verhalten für die Annahme einer Zertifikatsänderung


4.8.6 Veröffentlichung der Zertifikatsänderung durch die CA


4.8.7 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines neuen Zertifikats


4.9 Sperrung und Suspendierung von Zertifikaten

Der Sperrdient muss die (vorübergehende) Sperrfunktion „on Hold“ unterstützen. Ein

Zertifikat mit diesem Status darf nur unter definierten Umständen wieder von der Sperrliste

entfernt und somit wieder zugelassen werden. Diese Umstände müssen vom Coordination


Center Product PKI spezifiziert, gepflegt und den Berechtigten für eine Sperrung zugänglich

gemacht werden.

Das Coordination Center Product PKI muss nachrichtlich über jede Sperrung und den

Sperrgrund informiert werden.

4.9.1 Bedingungen für eine Sperrung

Bedingungen für die Sperrung eines Endzertifikats

Die CA soll ein End-Zertifikat sperren, falls einer oder mehrere der folgender Umstände

auftreten:

1. Der Zertifikatsinhaber verlangt schriftlich, dass die CA das Zertifikat sperrt;

2. Der Zertifikatsinhaber benachrichtigt die CA, dass die ursprüngliche

Zertifikatsignierungsanforderung (CSR) nicht autorisiert war und nicht rückwirkend

autorisiert wird;

3. Die CA erhält Nachweise darüber, dass der private Schlüssel des Zertifikatsinhabers,

der zum öffentlichen Schlüssel im Zertifikat gehört, kompromittiert worden ist oder nicht

länger die Anforderungen der Abschnitte 6.1.5 und 6.1.6 erfüllt;

4. Die CA erhält Nachweise darüber, dass das Zertifikat missbraucht worden ist;

5. Der CA wird bekannt gemacht, dass ein Zertifikatsinhaber gegen eine oder mehrere

materielle Verpflichtungen der Certificate Policy oder des Certification Practice

Statements verstoßen hat;

6. Der CA werden Umstände bekanntgemacht, die darauf hinweisen, dass die Nutzung

eines Fully-Qualified Domain Name oder einer IP-Addresse im Zertifikat nicht mehr legal

gestattet ist (z.B. ein Gericht hat einem Domain Name Registrant das Recht für die

Nutzung eines Domain Name entzogen, eine relevante Lizenzvereinbarung zwischen

dem Domain Name Registrant und dem Anmelder wurde gekündigt oder der Domain

Name Registrant hat den Domain Name nicht erneuert);

7. Der CA wird bekanntgemacht, dass ein Wildcard-Zertifikat für das Authentisieren von

einer irreführenden untergeordneten Fully-Qualified Domain Name genutzt worden ist;

8. Der CA wird bekanntgemacht, dass relevante Änderungen an den im Zertifikat

eingetragenen Informationen erfolgt sind;


9. Der CA wird bekannt gemacht, dass das Zertifikat nicht gemäß der Certificate Policy

oder des Certification Practice Statement der CA ausgestellt worden ist;

10. Die CA stellt fest, dass Informationen, die im Zertifikat erscheinen, nichtzutreffend oder

irreführend sind;

11. Die CA stellt den Betrieb ein und hat keine Vereinbarung mit einer anderen CA, eine

Unterstützung für die Sperrung des Zertifikats zu leisten;

12. Das Recht der CA Zertifikate unter diesen Anforderungen auszustellen läuft ab oder wird

aufgekündigt, außer wenn die CA Vereinbarungen getroffen hat, die

Sperrlistenverzeichnisse weiterzupflegen;

13. Der CA wurde bekanntgemacht, dass die privaten Schlüssel der untergeordneten CA,

die für die Ausstellung eines Zertifikats genutzt worden sind, möglicherweise

kompromittiert worden sind;

14. Eine Sperrung wird von der Certificate Policy und/oder vom Certification Practice

Statement verlangt;

15. Der technische Inhalt oder das Format vom Zertifikat stellt ein unakzeptables Risiko für

die Anwendungssoftwarelieferanten oder die vertrauenden Parteien dar (z.B. veraltete

Algorithmen);

16. Die CA erhält Nachweise darüber, dass das Zertifikat für andere Zwecke genutzt wird,

als innerhalb des Use Case vorgesehen;

17. Im Falle eines Fahrzeugzertifikats wird der CA wird bekanntgemacht, dass das

Steuergerät, das den privaten Schlüssel verwahrt, verloren gegangen oder beschädigt

worden ist, so dass es der Verdacht besteht, dass das integrierte Security-Modul

unsicher, beschädigt oder unbrauchbar ist;

18. Die CA erhält Nachweise darüber, dass das Computersystem oder das HSM, das den

Schlüssel verwaltet, kompromittiert worden ist;

19. Die CA erhält einen richterlichen Beschluss oder bei Gefahr im Verzuge eine Anordnung

durch die zuständigen Ermittlungsbehörden, ein bestimmtes Zertifikat zu sperren ohne

dass mildere Mittel zur Umsetzung der Anordnung gegeben sind.

Ursachen für die Sperrung eines untergeordneten CA-Zertifikats


Die ausstellende CA soll ein CA-Zertifikat einer untergeordneten CA sperren, falls einer oder

mehrere der folgenden Umstände auftreten:

1. Die untergeordnete CA verlangt schriftlich eine Sperrung;

2. Die untergeordnete CA benachrichtigt die ausstellende CA, dass die ursprüngliche

Zertifikatsignierungsanforderung (CSR) nicht autorisiert war und nicht rückwirkend

autorisiert wird;

3. Die ausstellende CA erhält Nachweise darüber, dass der private Schlüssel der

untergeordneten CA, der zum öffentlichen Schlüssel im Zertifikat gehört,

kompromittiert worden ist oder nicht länger die Anforderungen der Abschnitte 6.1.5

und 6.1.6 erfüllt;

4. Die ausstellende CA erhält Nachweise darüber, dass das Zertifikat missbraucht

worden ist;

5. Der ausstellenden CA wird bekanntgemacht, dass das Zertifikat nicht gemäß der

Certificate Policy oder der Certification Practice Statement der CA ausgestellt worden

ist;

6. Die ausstellende CA stellt fest, dass Informationen, die im Zertifikat erscheinen,

nichtzutreffend oder irreführend sind;

7. Die ausstellende oder die untergeordnete CA stellt den Betrieb ein und hat keine

Vereinbarung mit einer anderen CA, eine Unterstützung für die Sperrung des

Zertifikats zu leisten;

8. Das Recht der ausstellenden CA oder der untergeordneten CA, Zertifikate unter

diesen Anforderungen auszustellen läuft ab oder wird aufgekündigt, außer wenn die

CA Vereinbarungen getroffen hat, die Sperrlistenverzeichnisse weiterzupflegen;

9. Eine Sperrung wird von der Certificate Policy und/oder vom Certification Practice

Statement verlangt;

10. Der technische Inhalt oder das Format vom Zertifikat stellt ein unakzeptables Risiko

für die Anwendungssoftwarelieferanten oder die vertrauenden Parteien dar (z.B.

veraltete Algorithmen);

11. Die CA erhält Nachweise darüber, dass das Zertifikat für andere Zwecke genutzt

wird, als innerhalb des Use Case vorgesehen;


12. Die CA erhält Nachweise darüber, dass das Computersystem oder das HSM, das

den Schlüssel verwaltet, kompromittiert worden ist;

13. Die CA erhält einen richterlichen Beschluss oder bei Gefahr im Verzuge eine

Anordnung durch die zuständigen Ermittlungsbehörden, ein bestimmtes Zertifikat zu

sperren ohne dass mildere Mittel zur Umsetzung der Anordnung gegeben sind.

4.9.2 Berechtigte zur Beantragung einer Sperrung

Berechtigt zur Beantragung einer Sperrung (siehe auch 3.4) sind

• der jeweilige Zertifikatsinhaber

• die ausstellende CA selbst

• das Coordination Center Product PKI

• das Car Security Board im Rahmen von Security Incidents

jeweils unter Beachtung der unter 4.9.1 genannten Bedingungen für eine Sperrung.

4.9.3 Verfahren für einen Sperrantrag

Sperranträge sind grundsätzlich schriftlich zu stellen. Hierfür soll die Anlage 2 des CPS zu

dieser CP dargestellte Formular (Anlage_2_Sperrantrag_Product_PKI) genutzt werden. Der

digitale Sperrantrag muss (konzernintern) qualifiziert digital signiert sein oder in Papierform

unterschrieben werden.

4.9.4 Fristen für einen Sperrantrag

Fristen für einen Sperrantrag sollen nur im Rahmen der Incident-Behandlung ermittelt

werden.

4.9.5 Fristen/Zeitspanne für die Bearbeitung des Sperrantrags durch die CA

Die Bearbeitung des Sperrantrags muss (insbesondere im Rahmen der Incident-

Behandlung) unverzüglich nach Eingang bei der RA-Stelle der CA erfolgen.

4.9.6 Verfügbare Methoden zum Prüfen von Sperrinformationen

Für jede CA müssen separate Sperrlisten erzeugt werden.

Sperrlisten müssen jeweils von der CA signiert sein, zu der sie gehören.


4.9.7 Frequenz der Veröffentlichung von Sperrlisten

Sperrlisten müssen mindestens alle 8 Stunden erneuert werden und permanent

veröffentlicht werden. Nach Sperrung eines CA-Zertifikats oder eines Betriebs-End-Zertifikats

muss sofort von der CA, die das gesperrte Zertifikat signiert hatte, eine neue Sperrliste

erzeugt und zeitnah veröffentlicht werden.

Die Sperrlisten müssen eine Gültigkeitsdauer von 7 Tagen haben.

4.9.8 Maximale Latenzzeit für Sperrlisten

Die Veröffentlichung von Sperrlisten muss unmittelbar nach deren Erzeugung veranlasst

werden.

4.9.9 Verfügbarkeit von Online-Sperrinformationen

Die Bereitstellung von Online-Sperrinformationen wird nicht unterstützt, da es sich um die

Legacy PKI handelt (siehe 1.1).

4.9.10 Anforderungen zur Online-Prüfung von Sperrinformationen

Nicht vorhanden.

4.9.11 Andere Formen zur Anzeige von Sperrinformationen

Andere Formen als CRL brauchen nicht unterstützt werden.

4.9.12 Spezielle Anforderungen bei Kompromittierung des privaten Schlüssels

Bei der Kompromittierung des privaten Schlüssels eines Zertifikatsnehmers kann das

zugehörige Produkt-End-Zertifikat suspendiert werden. Einer Suspendierung kann eine

Sperrung folgen, eine Sperrung kann statt einer Suspendierung erfolgen.

4.9.13 Bedingungen für eine Suspendierung

Die Bedingungen für eine Suspendierung sind identisch mit den Bedingungen für eine

Sperrung, siehe daher Abschnitt 4.9.1. Eine Suspendierung darf nur stattfinden, wenn dies

beispielsweise zur Fehleranalyse o.ä. Analysen zur Behebung des Sperrgrundes

vorübergehend erforderlich ist.

4.9.14 Berechtigung zur Beantragung einer Suspendierung

Es gilt analog zur Sperrung Abschnitt 4.9.2.


4.9.15 Verfahren für Anträge auf Suspendierung

Es gilt analog zur Sperrung Abschnitt 4.9.3.

4.9.16 Begrenzungen für die Dauer von Suspendierungen

Das CSB, das CCPP oder der Leiter der CA müssen einzelfallbezogen über die Dauer von

Suspendierungen entscheiden. Sie müssen sich hierbei an die Vorgaben des CCPP halten

(siehe 4.9).

4.10 Statusabfragedienst für Zertifikate

4.10.1 Funktionsweise des Statusabfragedienstes

Es müssen ausschließlich Sperrlisten bereitgestellt werden.

4.10.2 Verfügbarkeit des Statusabfragedienstes

Aktuelle Statusabfragedienste (siehe 4.10.1) müssen permanent zur Verfügung stehen. Die

Dienste müssen für alle Zertifikatsnutzer verfügbar sein.

4.10.3 Optionale Leistungen

keine Vorgaben.

4.11 Kündigung durch den Zertifikatsnehmer

Da unter dieser CP keine Personenzertifikate erstellt werden dürfen, darf es keine

Kündigung durch Zertifikatsnehmer gegen.

4.12 Schlüsselhinterlegung und -wiederherstellung

4.12.1 Bedingungen und Verfahren für die Hinterlegung und Wiederherstellung privater Schlüssel

Private Schlüssel zu CA-Zertifikaten oder zu Betriebs-End-Zertifikaten dürfen außer im

Rahmen von HSM-Backup-Sicherungen (siehe Abschnitt 6.2.4) nur hinterlegt werden, wenn

sie ausschließlich mittels eines in einem HSM gespeicherten kryptografischen Schlüssels

nutzbar sind (siehe Abschnitt 6.2.3).


4.12.2 Bedingungen und Verfahren für die Hinterlegung und Wiederherstellung von Sitzungsschlüsseln (session keys)

Im Rahmen der UseCases, welche durch diese CA abgedeckt werden, dürfen

Sitzungsschlüssel nicht persistiert, sondern ausschließlich im RAM gehalten werden.


5 INFRASTRUKTURELLE, ORGANISATORISCHE UND PERSONELLE SICHERHEITSMASSNAHMEN

Dieser Abschnitt behandelt nicht-technische Sicherheitsmaßnahmen.

Nicht-technische Sicherheitsmaßnahmen müssen anhand dokumentierter Vorgaben und

Prozesse umgesetzt sein. Die Maßnahmen müssen ausreichen, um die in den Abschnitten

2 - 4 beschriebenen Anforderungen zu erfüllen.

5.1 Bauliche Sicherheitsmaßnahmen

Zentrale Komponenten der Volkswagen Group Product PKI müssen im besonderen Maße

gegen Ausfälle und Angriffe geschützt sein. Hierzu zählt auch die Beachtung der Regelung

der Informationssicherheit „03.05.01 Physischer Schutz“ für Anwendungen mit besonderer

Business-Kritikalität, die einen Mindest-Abstand von 100km für die Lagerung des Notfall-

Backup vorsieht.

5.1.1 Lage und Gebäude

Unterbringung von Soft- und Hardware einer CA muss in einem zutrittsgesicherten Bereich

in den Räumlichkeiten eines gesicherten Rechenzentrums der Volkswagen Group erfolgen,

die konkrete Verortung, Gesellschaft und Ort, muss im CPS zu diesem CP angegeben sein.

Weitere konkrete Anforderungen die an dieses Rechenzentrum gestellt werden, sind den

Unternehmensrichtlinien für Unternehmenskritische Anwendungen zu entnehmen.

5.1.2 Räumlicher Zugang

Die Server zentraler PKI-Funktionen müssen in einem zutrittsgesicherten Bereich in den

Räumlichkeiten eines gesicherten Rechenzentrums der Volkswagen AG untergebracht sein.

Der Zugang zu dem Rechenzentrum darf nur über abgesicherte Zonen möglich sein.

Innerhalb eines Rechenzentrums darf der physische Zugang zu den Servern nur für einen

speziellen Personenkreis in einem 4-Augen-Prinzip erfolgen.

Weitere konkrete Anforderungen die an dieses Rechenzentrum gestellt werden, sind den

Unternehmensrichtlinien für Unternehmenskritische Anwendungen zu entnehmen.


5.1.3 Stromversorgung und Klimaanlage

Systeme zentraler PKI-Funktionen müssen an eine unterbrechungsfreie Stromversorgung

angeschlossen sein und sollen über eine redundant ausgelegte Klimaanlage klimatisiert

werden.

5.1.4 Gefährdungen durch Wasser

Es müssen geeignete Maßnahmen ergriffen werden, die eine Gefährdung durch Wasser

weitgehend ausschließt.

5.1.5 Brandschutz

Ein für Systeme zentraler PKI-Funktionen verwendeter Serverraum soll über ein System zur

Brandfrühesterkennung mit einer Alarmaufschaltung zur Feuerwehr verfügen.

5.1.6 Aufbewahrung von Datenträgern

Träger sensibler Daten müssen so aufbewahrt werden, dass ein Zugriff durch Unbefugte

weitgehend verhindert wird.

5.1.7 Müllbeseitigung

Die Brandschutzvorgaben der Volkswagen AG müssen eingehalten werden.

Träger sensibler Daten müssen vor ihrer Beseitigung gemäß den

Datensicherheitsbestimmungen für als „geheim“ klassifizierte Daten der Volkswagen Gruppe

unlesbar gemacht werden.

5.1.8 Externe Datensicherung

Soweit für die Server der CA-Dienste eine Datensicherung außerhalb der zutrittsbegrenzten

Bereiche (siehe Abschnitt 5.1.2) abgelegt wird, müssen sensible Daten verschlüsselt sein.

5.2 Verfahrensvorschriften

5.2.1 Rollenkonzept

Es muss ein Rollenkonzept mit dem Ziel dokumentiert und umgesetzt sein, die

Auswirkungen eines Missbrauchs durch einzelne Funktionsträger zu reduzieren bzw. die

Möglichkeiten zum Missbrauch einzuschränken.


5.2.2 Mehraugenprinzip

Sicherheitsrelevante Vorgänge sollen nach dem 4-Augen-Prinzip durchgeführt werden.

Arbeiten innerhalb eines gesicherten Bereichs, der zentrale Komponenten der Volkswagen

Product PKI enthält, müssen nach dem 4-Augen-Prinzip durchgeführt werden.

Nicht permanent berechtigte Personen müssen bei einem Zugang zu gesicherten Bereichen

mit zentralen Komponenten der Volkswagen Product PKI von mindestens einer berechtigten

Person permanent begleitet werden.

5.2.3 Identifizierung und Authentifizierung einzelner Rollen

Für jede PKI-Funktionsstelle muss ein Leiter entweder vom bisherigen Leiter der

Funktionsstelle oder von CISO/LISO der betreibenden Gesellschaft benannt sein. Diese

Benennung muss dokumentiert und von der benennenden Person unterschrieben sein.

Funktionsträger (außer Leitern der Funktionsstelle; dazu siehe oben) der Volkswagen

Product PKI einschließlich der RAs müssen durch den Leiter der jeweiligen Funktionsstelle

namentlich benannt und den jeweiligen Rollen zugeordnet sein. Die Zuordnung von

Personen zu Rollen muss dokumentiert und vom Leiter der Funktionsstelle unterschrieben

sein.

Eine Freischaltung für Rollen, die Änderungen an Zertifikaten oder PKI-

Sicherheitseinstellungen vornehmen dürfen (RA-Officer oder Security-Officer) muss nach

dem Vier-Augen-Prinzip durch zwei Security Officer (SO) erfolgen.

5.2.4 Rollentrennung

Die Funktionsrollen müssen so getrennt sein, dass sensible Vorgänge nicht durch eine

einzelne Person durchgeführt werden können.

Es muss mindestens zwischen folgenden Rollen unterschieden werden:

• Leiter der CA: o Leitet die CA

o nimmt Leitungs- und Steuerungsaufgaben war

o legitimiert interne Prozesse

o bestätigt Sperranträge oder lehnt diese ab (außer im Incident-Fall)

• RA-Officer: o Nimmt Anträge auf Zertifikate und Sperranträge entgegen und prüft diese.


o Initiiert den Zertifikatsausstellungs- oder Sperrprozess für CA-Zertifikate

o Berechtigung zur Erstellung oder Sperrung von End-Zertifikaten.

o Kommuniziert als RA-Stelle mit den Antragsstellern und holt die Bestätigung

vom Leiter CA ein.

o betreut die RA-Stelle mit allen Aufgaben einer Registration Authority

• Security Officer: o hat alle Rechte eines RA-Officer und zusätzlich:

o Berechtigung zur Erstellung oder Sperrung von CA-Zertifikaten.

o Kann CAs erstellen, aktivieren, deaktivieren, verändern und löschen

o Kann Schlüssel erstellen, aktivieren, deaktivieren und löschen

o Kann Zertifikatsformate festlegen, editieren und löschen

o Kann Regeln und Prozesse innerhalb der CA-Software definieren

o Kann Rollen anlegen und zuweisen, sowie Berechtigungen definieren

o Kann Protokolle aufrufen

o Kann die CA-Software konfigurieren (sofern zutreffend)

RA-Officer-Aufgaben sollen und Security-Officer-Aufgaben müssen durch mindestens 2

Officer freigegeben werden.

Security Officer können auch alle RA-Officer-Aufgaben durchführen, d.h. die Security

Officer-Rolle inkludiert die RA-Officer-Rolle. Nicht umgekehrt!

• Anwendungsprogrammierer:

Programmierer für Anwendungen, durch die die PKI-Funktionen in der Funktionsstelle zur

Verfügung gestellt werden.

5.3 Personalkontrolle

5.3.1 Anforderungen an Qualifikation, Erfahrung und Zuverlässigkeit

Der Leiter einer PKI-Funktionsstelle muss dafür sorgen, dass das jeweilige

Funktionspersonal die notwendigen Qualifikationsmaßnahmen erhält.

Funktionsträger der Volkswagen PKI müssen Mitarbeiter der Volkswagen Group sein und

sollen zu der Gesellschaft gehören, die für die Funktionsstelle verantwortlich ist.

5.3.2 Sicherheitsüberprüfung von Mitarbeitern

Keine Vorgaben


5.3.3 Anforderungen an Schulungen

Mitarbeiter einer PKI-Funktionsstelle müssen regelmäßig sowie im Bedarfsfall geschult

werden. Die Verantwortung für diese Maßnahmen trägt der Leiter der jeweiligen PKI-

Funktionsstelle.

5.3.4 Häufigkeit von Schulungen und Belehrungen

Keine Vorgaben

5.3.5 Häufigkeit und Ablauf von Arbeitsplatzwechseln (Job Rotation)

Keine Vorgaben

5.3.6 Sanktionen für unerlaubte Handlungen

Es gelten mindestens die Verhaltens- und Compliance-Regeln der Volkswagen Group.

5.3.7 Anforderungen an freie Mitarbeiter

Mitarbeiter beauftragter Partnergesellschaften dürfen nur im Rahmen der bestehenden

Richtlinien und Organisationsanweisungen der Volkswagen Group eingesetzt werden.

5.3.8 An Mitarbeiter auszuhändigende Dokumentation

Den Mitarbeitern der CA müssen die notwendigen Dokumente zur Erfüllung ihrer Aufgaben

und zur Durchführung des Betriebes der CA (siehe [A1]) zur Verfügung gestellt werden.

Zu den notwendigen Dokumenten zählen wenigstens:

- Certificate Policy (CP),

- Certification Practice Statement (CPS),

- Betriebshandbücher und Benutzeranleitungen

- relevante interne Anweisungen.

5.4 Überwachungs- und Protokollierungsmaßnahmen

5.4.1 Arten aufgezeichneter Ereignisse

Alle Transaktionen zwischen CA, RA und Verzeichnissen, die zu einer Erzeugung von

Schlüsselmaterial oder Zertifikaten, zur Sperrung bzw. Wiederfreigabe von Zertifikaten, zum


Export von Schlüsselmaterial aus einer geschützten Umgebung oder zur Veränderung von

sicherheitsrelevanten Konfigurationen führen, müssen protokolliert werden.

Alle Administrationstätigkeiten auf Systemen der Volkswagen Product PKI müssen

protokolliert werden.

5.4.2 Häufigkeit der Bearbeitung von Aufzeichnungen

Für die Bearbeitung von Aufzeichnungen von Aktionen in PKI-Funktionsstellen muss ein

Konzept erstellt werden.

Zusätzlich können die Aufzeichnungen nach Bedarf bearbeitet werden.

5.4.3 Aufbewahrungszeit von Aufzeichnungen

Die Aufbewahrungszeit muss den relevanten rechtlichen Anforderungen genügen.

5.4.4 Schutz von Aufzeichnungen

Die Aufzeichnungen müssen gemäß den rechtlichen und den Volkswagen-internen

Anforderungen geschützt sein. Dabei müssen auch die Anforderungen an die Integrität der

Aufzeichnungen erfüllt werden.

Es gelten auch die Anforderungen wie in Abschnitt 5.1.8.

5.4.5 Sicherung von Aufzeichnungen (Backup)

Die Aufzeichnungen müssen gemäß den rechtlichen und den Volkswagen-internen

Anforderungen gesichert sein.

5.4.6 Speicherung von Aufzeichnungen (intern / extern)

Die Speicherung der Aufzeichnungen muss den rechtlichen und den Volkswagen-internen

Anforderungen genügen.

5.4.7 Benachrichtigung der Ereignisauslöser

Keine Vorgaben

5.4.8 Schwachstellenanalyse

In die Schwachstellenanalyse von Systemen der Volkswagen Product PKI müssen

Empfehlungen und Beobachtungen des CERTs und der jeweiligen Hersteller einfließen.


5.5 Archivierung von Aufzeichnungen

Die Archivierung der Aufzeichnungen muss den rechtlichen und den Volkswagen-internen


5.5.1 Arten archivierter Aufzeichnungen

Folgende Daten müssen archiviert werden, soweit eine Verfügbarkeit der Aufzeichnungen

nicht im Rahmen der Sicherungen gewährleistet ist:

• Beantragungsinformationen / Beantragungsformulare zu Zertifikaten

• Ausgabeprotokolle zu Zertifikaten

• Sperranträge zu Zertifikaten

• Protokollierungen von sicherheitsrelevanten PKI-Vorgängen (siehe Abschnitt 5.4.1)

5.5.2 Aufbewahrungsfristen für archivierte Daten

Die Aufbewahrungsfristen der archivierten Daten müssen den rechtlichen und den

Volkswagen-internen Anforderungen genügen.

5.5.3 Schutz des Archivs

Der Schutz der archivierten Daten muss den rechtlichen und den Volkswagen-internen


5.5.4 Datensicherung des Archivs (Backup)

Die Datensicherung der archivierten Daten muss den rechtlichen und den Volkswagen-

internen Anforderungen genügen.

5.5.5 Anforderungen zum Zeitstempeln von Aufzeichnungen

Die Anforderungen zum Zeitstempeln von Aufzeichnungen müssen den rechtlichen und den

Volkswagen-internen Anforderungen genügen.

5.5.6 Archivierung (intern / extern)

CA-Zertifikate müssen gemäß KSU für mindestens 15 Jahre aufbewahrt werden. Zur

Aufbewahrung muss das interne DMS genutzt werden.


5.5.7 Verfahren zur Beschaffung und Verifikation von Archivinformationen

Die Verfahren müssen den rechtlichen und den Volkswagen-internen Anforderungen

genügen.

5.6 Schlüsselwechsel einer CA

Schlüsselwechsel einer CA bedeutet Ausstellung eines neuen CA-Zertifikats.

Die Namen der CA-Zertifikate müssen gemäß Abschnitt 3.1.1 gebildet werden. Wenn für

eine CA ein neues Zertifikat erstellt wird, soll die 3-stellige Nummer im Zertifikatsnamen um

1 erhöht werden. Ausnahmen dürfen nur mit Zustimmung der Stelle erfolgen, die für die

ausstellende CA verantwortlich ist (siehe [V4]).

Rechtzeitig vor dem Zeitpunkt, ab dem Zertifikate von dem neuen CA-Zertifikat ausgegeben

werden, müssen alle Zertifikatsnutzer des CA-Zertifikats über den Zertifikatswechsel

informiert werden (siehe auch Abschnitt 2).

Gültigkeitsperioden von Schlüsselpaaren und Zertifikaten sind in Abschnitt 6.3.2

beschrieben.

Die folgenden Aussagen dieses Abschnitts gelten nur für den Fall, dass CA-Schlüssel nicht

kompromittiert sind. Aussagen zu Kompromittierungs-Fällen sind in Abschnitt 5.7 enthalten.

Root-CA:

• Erstellung eines neuen CA-Zertifikats: nach maximal 24 Jahren.

Level-1-Sub-CAs:


Level-2-Sub-CAs, soweit deren Zertifikate unter dieser CP erstellt werden (siehe Abschnitt

1.3.1


Der Informationszeitraum für Zertifikatsnutzer über einen CA-Zertifikatswechsel soll wenigstens 1 Jahr betragen.

Von einem Nachfolge-Zertifikat einer CA sollen nur dann Zertifikate erstellt werden, wenn

die Laufzeit des vorangehenden CA-Zertifikats die Laufzeit des zu erstellenden Zertifikats

unterschreitet oder die Zertifikatsparameter des alten Zertifikats nicht mehr das geforderte

Sicherheitsniveau gewährleisten kann.


Gültigkeitsprüfung für ein neues CA-Zertifikat durch Zertifikatsnutzer:

• Root-CA:

Ein neues Root-CA-Zertifikat darf nur dann als gültig akzeptiert werden,

o wenn es in einem Daten-Container bereitgestellt wird, der von einem

Container-Signierer-Zertifikat signiert wurde, das gültig ist und unter der bisher

gültigen Root-CA ausgestellt wurde;

o wenn es in einem spezifischen Container bereitgestellt wird, der auch für die

Bereitstellung des ersten ROOT-CA-Zertifikats genutzt werden durfte.

o wenn es auf gleichem authentischem Wege bereitgestellt wird, wie das

vorangegangene Root-Zertifikat

• Sub-CAs:

Ein neues Sub-CA-Zertifikat darf nur dann als gültig akzeptiert werden, wenn es von

einem gültigen übergeordneten CA-Zertifikat ausgegeben wurde.

5.7 Kompromittierung und Notfallplanung

In diesem Abschnitt werden die Fälle behandelt, in denen

• ein privater CA-Schlüssel durch Unbefugte nutzbar wurde

(Schlüsselkompromittierung).

In diesem Fall müssen folgende Stellen informiert werden:

o Verantwortliche der CA

o Funktions-/Produkt-Verantwortliche

o Coordination Center Product PKI

o Car Security Incident Team (der betroffenen Konzern-Marke)

• ein privater CA-Schlüssel durch die befugten Stellen nicht mehr nutzbar und auch

nicht wiederherstellbar ist (Schlüsselverlust).

In diesem Fall müssen folgende Stellen informiert werden:

o Verantwortliche der CA

o Funktions-/Produkt-Verantwortliche

o Coordination Center Product PKI

In beiden Fällen muss zur Aufrechterhaltung des PKI-Betriebs kurzfristig ein neues CA-

Zertifikat mit einem neuen Schlüssel erstellt werden. Es gelten die entsprechenden

Aussagen in Abschnitt 5.6.


Die Information der Zertifikatsnutzer muss unverzüglich erfolgen.

5.7.1 Behandlung von Vorfällen und Kompromittierungen

Entsprechende Vorfälle müssen als Sicherheitsvorfall (Security Incident) bewertet und

behandelt werden. Der Verantwortliche der CA muss dafür Sorge tragen, dass die mit dem

Betrieb der CA betrauten Personen über das entsprechende Knowhow verfügen, um jede Art

von Incident angemessen zu erkennen und zu behandeln. Dafür sollen entsprechende

Incident-Pläne vorbereitet und Metriken entworfen werden, die bei Erkennung und

Behandlung unterstützen.

5.7.2 Kompromittierung von Rechnerressourcen, Software oder Daten

Wenn durch die Kompromittierung von Rechnern, Software oder Daten eine unbefugte

Nutzung eines privaten CA-Schlüssels zu befürchten ist, muss der Prozess für Car Security

Incidents genutzt werden, der wiederum die Klärung zusammen mit dem Car Security Board

und dem Coordination Center Product PKI durchführt. Ausschließlich über diesen Prozess

dürfen das entsprechende CA-Zertifikat und alle von dem CA-Zertifikat erstellten Zertifikate

gesperrt werden.

Bei der Bewertung durch das Car Security Board unter Mitwirkung des Coordination Center

Product PKI müssen alle Auswirkungen geprüft werden, die eine Gefahr für Leben oder

Gesundheit von Betroffenen bedeuten. Die Zertifikate dürfen erst dann gesperrt werden,

wenn z.B. durch Ausgabe neuer Zertifikate die Gefährdung vermieden werden kann.

Vor Ausgabe eines neuen CA-Zertifikats muss hinreichend sichergestellt werden, dass die

eingesetzten Rechner, Software oder Daten nicht kompromittiert sind.

5.7.3 Kompromittierung des privaten Schlüssels einer CA

Es muss dafür gesorgt werden, dass die Ursachen der Schlüsselkompromittierung

unverzüglich abgestellt werden.

Wenn ein hinreichender Verdacht auf Kompromittierung eines privaten CA-Schlüssels

besteht, müssen alle Zertifikate zu dem entsprechenden öffentlichen Schlüssel gesperrt

werden. Damit müssen auch alle Zertifikate, die unter diesen Zertifikaten ausgegeben

wurden, als ungültig betrachtet werden.

Bei der Bewertung durch das Car Security Board unter Mitwirkung des Coordination Center

Product PKI müssen alle Auswirkungen geprüft werden, die eine Gefahr für Leben oder


Gesundheit von Betroffenen bedeuten. Wenn aufgrund der Sperrung des CA-Zertifikats oder

der darunter ausgegebenen Zertifikate durch den Ausfall von Fahrzeugfunktionen

Situationen auftreten können, die eine Gefahr für Leben oder Gesundheit von Betroffenen

bedeuten, dürfen die Zertifikate erst dann gesperrt werden, wenn durch geeignete

Maßnahmen (z.B. durch Ausgabe neuer Zertifikate) die Gefährdung vermieden wurde.

5.7.4 Möglichkeiten zur Geschäftsweiterführung nach einer Kompromittierung

Nach einer Kompromittierung sollen die Voraussetzungen für den Weiterbetrieb der

Volkswagen Group Product PKI geschaffen werden (siehe Abschnitte 5.7.2 und 5.7.3).

5.8 Schließung von CA oder RA

Über eine Schließung von CA oder RA muss die Stelle entscheiden, die für die Volkswagen

Group Product PKI verantwortlich ist (siehe [V4]).

Alle von der Schließung betroffenen Stellen müssen rechtzeitig informiert werden. Der

Ablauf einer Schließung muss in einem separaten Dokument beschrieben werden.


6 TECHNISCHE SICHERHEITSMASSNAHMEN

6.1 Erzeugung und Installation von Schlüsselpaaren

6.1.1 Erzeugung von Schlüsselpaaren

Schlüssel für CA- oder Betriebs-End-Zertifikate, die unter Anwendung dieser CP signiert

werden, müssen auf oder mittels HSMs generiert werden. Je nach Verwendung der

Zertifikate können unterschiedliche Bereiche von HSMs genutzt werden.

Die Schlüssel dürfen die HSMs außer zu Backup-Zwecken (siehe Abschnitt 6.2.4) nicht verlassen.

Anforderungen für die Erzeugung von Produkt-End-Zertifikaten müssen in der CP

beschrieben sein, die für den Betrieb der ausstellenden CA angewandt wird.

6.1.2 Lieferung privater Schlüssel an Zertifikatsnehmer

Die Anwendungen, für die CA-oder Betriebs-End-Zertifikate erstellt werden, erhalten Zugriff

auf das jeweilige HSM. Dabei darf der Zugriff nur auf den HSM-Bereich eingerichtet werden,

in dem sich der jeweilige private Schlüssel befindet.

Anforderungen für die Bereitstellung privater Schlüssel für Produkt-End-Zertifikate an

Zertifikatsnehmer müssen in der CP beschrieben sein, die für den Betrieb der ausstellenden

CA angewandt wird.

6.1.3 Lieferung öffentlicher Schlüssel an Zertifikatsherausgeber

Der öffentliche Schlüssel muss im Rahmen des Zertifikatsantrags an die Zertifikats-

signierende CA übergeben werden.

6.1.4 Lieferung öffentlicher CA-Schlüssel an Zertifikatsnutzer

Die CA-Zertifikate und damit deren öffentliche Schlüssel müssen in einem Verzeichnis so

zur Verfügung gestellt werden, dass die Zertifikatsnutzer sie abrufen können (siehe Abschnitt

2.2). Dasselbe gilt auch für Betriebs-End-Zertifikate.

6.1.5 Schlüssellängen

Es müssen Schlüssel des Typs ECDSA verwendet werden. Die Schlüssellänge muss

mindestens 256 Bit betragen.


6.1.6 Festlegung der Parameter öffentlicher Schlüssel und Qualitätssicherung

Es müssen Parameter verwendet werden, die mindestens das Sicherheitsniveau von

secp256r1 erreichen.

6.1.7 Schlüsselverwendungen

Es dürfen nur folgende Schlüsselverwendungen (siehe Network Working Group RFC 5280)

genutzt werden:

CA-Zertifikate (siehe Abschnitt 1.3.1): keyCertSign, cRLSign

erweiterte Schlüsselverwendung: keine

Betriebs-End-Zertifikate zur Signatur von CA-Zertifikats-Containern digitalSignature

erweiterte Schlüsselverwendung: keine

Die Anforderungen an Schlüsselverwendungen von Produkt-End-Zertifikaten müssen in der

CP, die auf den Betrieb der ausstellenden CA anzuwenden ist, beschrieben sein.

6.2 Schutz des privaten Schlüssels und Anforderungen an kryptographische Module

6.2.1 Standards und Sicherheitsmaßnahmen für kryptographische Module

Soweit private Schlüssel auf HSMs gespeichert werden (siehe Abschnitt 6.1.1), müssen die

verwendeten kryptographischen Module anerkannten (Sicherheits-) Standards genügen.

Diese sollen die Anforderungen der Standards FIPS PUB 140-1, 140-2 (Level 2 oder höher)

erfüllen, über eine EAL4-Zertifizierung (oder höher) verfügen oder einem vergleichbaren

Standard genügen.

6.2.2 Mehrpersonen-Zugriffsicherung auf private Schlüssel

Soweit private Schlüssel auf HSMs gespeichert werden (siehe Abschnitt 6.1.1), darf eine

Freischaltung eines HSMs zur Nutzung der privaten Schlüssel nur durch mehrere Personen

nach einem n-von-m-Prinzip erfolgen.

6.2.3 Hinterlegung privater Schlüssel

Eine Hinterlegung von privaten Schlüsseln für CA-Zertifikate oder für Betriebs-End-Zertifikate

darf nicht außerhalb der verwendeten HSMs oder deren Backup-Datenträgern erfolgen

(siehe auch Abschnitt 6.1.1).


Anforderungen zur Hinterlegung privater Produkt-End-Zertifikats-Schlüssel müssen in der

CP beschrieben sein, die auf den Betrieb der ausstellenden CA anzuwenden ist.

6.2.4 Sicherung privater Schlüssel (Backup)

Die zur Speicherung von privaten Schlüsseln verwendeten HSM müssen hochverfügbar und

katastrophensicher aufgestellt sein. D. h., dass mindestens 2 Hardware-Installationen an

verschiedenen Standorten bestehen müssen, die einen genügenden räumlichen Abstand

haben. Dabei müssen die Sicherheitsvorgaben der Volkswagen Group bezüglich der

Katastrophensicherheit eingehalten werden. (siehe auch Abschnitt Fehler! Verweisquelle konnte nicht gefunden werden.)

Backup-Sicherungen der privaten Schlüssel müssen mindestens dasselbe

Sicherheitsniveau erfüllen wie die HSMs selbst.

Anforderungen zur Sicherung privater Produkt-End-Zertifikats-Schlüssel müssen in der CP

beschrieben sein, die auf den Betrieb der ausstellenden CA anzuwenden ist.

6.2.5 Archivierung privater Schlüssel

Abgesehen von den in den Abschnitten 6.2.3 und 6.2.4 beschriebenen Fällen dürfen private

CA- oder Betriebs-End-Zertifikats-Schlüssel nicht archiviert werden.

Anforderungen zur Archivierung privater Produkt-End-Zertifikats-Schlüssel müssen in der


6.2.6 Transfer privater Schlüssel in oder aus kryptographischen Modulen

Außer zur Sicherung aus und zum Wiedereinspielen in HSMs dürfen private Schlüssel von

CA- oder Betriebs-End-Zertifikaten nicht übertragen werden.

Anforderungen zum Transfer privater Produkt-End-Zertifikats-Schlüssel müssen in der CP


6.2.7 Speicherung privater Schlüssel in kryptographischen Modulen

Private Schlüssel von CA- oder Betriebs-End-Zertifikaten dürfen nur in HSMs gemäß

Abschnitt 6.2.1 oder deren Backup-Sicherungen gespeichert sein.

Anforderungen zur Speicherung privater Produkt-End-Zertifikats-Schlüssel müssen in der



6.2.8 Aktivierung privater Schlüssel

Private Schlüssel für CA-Zertifikate dürfen nur unter Einhaltung des 4-Augen-Prinzips von

dafür autorisierten Funktionsträgern aktiviert werden.

Private Schlüssel für Betriebs-End-Zertifikaten brauchen nicht zusätzlich zu einer

Zertifikatserstellung aktiviert zu werden.

Anforderungen zur Aktivierung privater Produkt-End-Zertifikats-Schlüssel müssen in der CP


6.2.9 Deaktivierung privater Schlüssel

Private Schlüssel für CA-Zertifikate dürfen nur unter Einhaltung des 4-Augen-Prinzips von

dafür autorisierten Funktionsträgern deaktiviert werden.

Private Schlüssel für Betriebs-End-Zertifikaten brauchen nicht zusätzlich zu einer

Zertifikatssperrung oder einem Zertifikatsablauf deaktiviert zu werden.

Anforderungen zur Deaktivierung privater Produkt-End-Zertifikats-Schlüssel müssen in der


6.2.10 Zerstörung privater Schlüssel

Es muss sichergestellt sein, dass private Signaturschlüssel von CA- oder Betriebs-End-

Zertifikaten nach Ende ihres Lebenszyklus nicht mehr benutzt werden. Dazu sollen sie unter

Einhaltung des 4-Augen Prinzips von dafür autorisierten Funktionsträgern zerstört bzw.

gelöscht werden.

Anforderungen zur Zerstörung privater Produkt-End-Zertifikats-Schlüssel müssen in der CP


6.2.11 Bewertung kryptographischer Module



6.3 Andere Aspekte des Managements von Schlüsselpaaren

6.3.1 Archivierung öffentlicher Schlüssel

Öffentliche Schlüssel von CA- oder Betriebs-End-Zertifikaten werden in Form von Zertifikaten

in einem internen Verzeichnis des PKI-Systems verfügbar gehalten. Dabei müssen die

Zertifikate mindestens 10 Jahren nach Ablauf der Zertifikatsgültigkeit verfügbar sein.

Anforderungen zur Archivierung öffentlicher Produkt-End-Zertifikats-Schlüssel müssen in

der CP beschrieben sein, die auf den Betrieb der ausstellenden CA anzuwenden ist.

6.3.2 Gültigkeitsperioden von Zertifikaten und Schlüsselpaaren

Es müssen folgende Zeiträume für die Zertifikatsgültigkeiten eingehalten werden:

Für Zertifikate dürfen folgende Gültigkeitsperioden nicht überschritten werden:

• Root-CA-Zertifikate: 30 Jahre

• Level-1-Sub-CA-Zertifikate: 30 Jahre

• Level-2-Sub-CA-Zertifikate (siehe Abschnitt 1.3.1): 30 Jahre

• Betriebs-End-Zertifikate: 30 Jahre

• Produkt-End-Zertifikate: 30 Jahre

Für Nachfolgezertifikate für ein CA- oder ein End-Zertifikat muss ein neues Schlüsselpaar

verwendet werden.

Schlüssel für CA-Zertifikate dürfen nicht länger als 3 Monate vor dem Zeitpunkt erstellt

werden, an dem zu dem öffentlichen Schlüssel erstmalig ein Zertifikat erstellt wird

6.4 Aktivierungsdaten

6.4.1 Erzeugung und Installation von Aktivierungsdaten

Zur Aktivierung von Schlüsseln siehe Abschnitt 6.2.8. Darüber hinaus werden keine

Aktivierungsdaten erzeugt.

6.4.2 Schutz von Aktivierungsdaten

keine Vorgaben.


6.4.3 Andere Aspekte von Aktivierungsdaten

keine Vorgaben.

6.5 Sicherheitsmaßnahmen für IT-Systeme

6.5.1 Spezifische technische Sicherheitsanforderungen für IT-Systeme

Alle IT-Komponenten der Volkswagen Legacy Product PKI müssen die für sie geltenden

Sicherheitsanforderungen der IT-Sicherheitsrichtlinien (siehe [1]) erfüllen.

IT-Systeme (Server) für den Web-Sperrdienst sollen mit geeigneten Maßnahmen gegen

unberechtigte Veränderungen geschützt werden.

Ressourcenanforderungen einer CA an CPU und Speicher sollen überwacht und

Auswertungen vorgenommen werden. Die dabei gewonnenen Erkenntnisse müssen in die

Kapazitätsplanung der CA einfließen.

Auf den IT-Komponenten sollen nur die zu den PKI-Funktionen sowie zur Administration der

Systeme notwendigen Kommunikationsbeziehungen zugelassen werden.

Siehe auch Abschnitt 6.7.

6.5.2 Beurteilung der IT-Systemsicherheit

Eine Beurteilung muss mindestens im Rahmen interner Audits gemäß dem Volkswagen

Group Standard für Konzerngesellschaften erfolgen. Die Auditoren müssen entsprechende

Auditor-Zertifizierungen besitzen.

6.6 Technische Maßnahmen während des Lebenszyklusses

Die für CA verantwortliche Stelle (siehe [V4]) muss über aktuelle Sicherheitsstandards

informiert sein.

Mindestanforderungen des BSI sollen und die Regelungen der Volkswagen Group müssen

eingehalten werden, sofern diese für den Einsatzbereich der Volkswagen Product PKI

relevant sind und den laufenden Betrieb von Applikationen innerhalb der Volkswagen Group

nicht gefährden.

6.6.1 Sicherheitsmaßnahmen bei der Systementwicklung

keine Vorgaben


6.6.2 Sicherheitsmaßnahmen beim Systemmanagement

keine Vorgaben

6.6.3 Sicherheitsmaßnahmen während des Lebenszyklusses

Alle IT-Komponenten der Volkswagen Legacy Product PKI müssen die für sie geltenden

Sicherheitsanforderungen der IT-Sicherheitsrichtlinien (siehe [1]) erfüllen

6.7 Sicherheitsmaßnahmen für Netze

Alle Netz-Komponenten der Volkswagen Legacy Product PKI müssen die für sie geltenden

Sicherheitsanforderungen der IT-Sicherheitsrichtlinien (siehe [1]) erfüllen.

CAs, RAs sowie IT-Komponenten der Level 0 (Root) und 1 (Intermediate CAs) der

Volkswagen Group Product PKI dürfen nur in internen Netzwerkzonen des Volkswagen

Konzerns betrieben werden, die die jeweiligen Sicherheitsanforderungen erfüllen.

Verzeichnisdienste und Dienste für Gültigkeitsinformationen können bei Bedarf auch über

andere interne oder externe Netze abrufbar sein

6.8 Zeitstempel

keine Vorgaben


7 PROFILE VON ZERTIFIKATEN, SPERRLISTEN UND OCSP

7.1 Zertifikatsprofile

Alle Zertifikate müssen folgende Inhalte enthalten:

• Identifizierung der ausstellenden CA • Angabe der Organisation und des Landes, in dem der Zertifikatsnehmer angesiedelt

ist • Der Name des Zertifikatinhabers als Common Name • Der öffentliche Schlüssel, der mit dem privaten Schlüssel unter der Kontrolle des

Zertifikatinhabers korrespondiert • Das Anfangs- und Enddatum der Gültigkeitsperiode des Zertifikats • Die Seriennummer des Zertifikats, die innerhalb des CA-Typs eindeutig sein muss • Die elektronische Signatur der ausstellenden CA • Schlüsselverwendung (key usage) • Einschränkungen der Einsatzmöglichkeiten des Zertifikats

7.1.1 Versionsnummern

Zertifikate, die unter dieser CP erstellt werden, müssen konform zum Standard X.509 v3

(Typ 0x2) gemäß RFC 5280 sein.

7.1.2 Zertifikatserweiterungen

Zertifikatserweiterungen, die in den Zertifikaten verwendet werden, die von einer CA unter

Anwendung dieser CP signiert werden, müssen im CPS dieser CA beschrieben und sowohl

zu PKIX als auch zum RFC 5280 konform sein.

Zertifikate für CAs In Zertifikaten für CAs, soweit unter dieser Policy erstellt, müssen die Erweiterungen

keyUsage mit den Werten „KeyCertSign“ und cRLSign“ sowie die Erweiterung

basicConstraints mit dem Wert „CA=True“ aufgenommen werden. Des Weiteren beinhalten

Zertifikate für CAs der Level 1 eine Erweiterung cRLDistributionPoint mit einem Verweis auf

die unter 2.1 genannte Adresse, welche um den CA-Namen, wie in 3.1.1 definiert, ergänzt

wird, welcher auf „.CRL“ enden muss.

Die beiden Erweiterungen keyUsage und basicConstraints müssen mit dem Flag „critical“

versehen sein.

End-Zertifikate Ein End-Zertifikat muss mit der Erweiterung „basicConstraints“ mit dem Wert „CA=False“ als


Nicht-CA-Zertifikat markiert sein und darf nicht CA-spezifische keyUsage-Erweiterungen

führen, d.h. die Erweiterung „keyUsage“ darf nicht den Wert „keyCertSign“ tragen.

Die keyUsage-Erweiterung darf nur mit dem Wert „nonRepudiaton“ belegt werden, wenn

keine Wiederherstellung des privaten Schlüssels möglich ist und dieser durch technische

und organisatorische Maßnahmen nur dem Zertifikatinhaber zugänglich ist.

Die beiden Erweiterungen keyUsage und basicConstraints müssen mit dem Flag „critical“

versehen sein.

Alle End-Zertifikate müssen immer die keyUsage-Erweiterungen digitalSignature sowie

keyAgreement enthalten und müssen zudem mit der ExtendedKeyUsage clientAuth und

serverAuth versehen werden.

End-Zertifikate müssen außerdem immer die Erweiterung cRLDistribution Point mit einem

Verweis auf die zugehörige Sperrliste enthalten.

7.1.3 Algorithmen OIDs

Objekt Indentifikatoren für Algorithmen müssen nach PKIX verwendet werden.

7.1.4 Namensformate

Siehe auch Abschnitt 3.1

7.1.5 Namensbeschränkungen


7.1.6 OIDs der Zertifikatsrichtlinien


7.1.7 Nutzung der Erweiterung „PolicyConstraints”

Die Erweiterung darf nicht genutzt werden.

7.1.8 Syntax und Semantik der Erweiterung „PolicyQualifiers“

Die Erweiterung darf nicht genutzt werden.

7.1.9 Verarbeitung der Semantik der kritischen Erweiterung „CertificatePolicies“


Die Erweiterung muss in den Zertifikaten einen Verweis auf die OID dieser für sie relevanten

Policy (siehe 1.2) enthalten. Diese Erweiterung braucht von nutzenden Anwendungen nicht verarbeitet werden zu können.

7.2 Sperrlistenprofile

Für jede CA in der Volkswagen Product PKI muss eine CRL bereitgestellt werden. Diese

muss die untergeordneten gesperrten Zertifikate enthalten, die von der jeweiligen CA

signiert wurden. Jede CRL muss folgende Informationen enthalten:

• Versionsnummer • Signaturalgorithmus • Identifizierung des Signierers • Zeitpunkt der Ausstellung • Spätester Zeitpunkt des nächsten Updates • Seriennummern und Sperrungsdaten der gesperrten Zertifikate • Die elektronische Signatur des Signierers

Sperrlisten müssen im DER-Format kodiert sein.


Die Sperrlisten müssen der Norm X.509 in der Version 2 entsprechen.

7.2.2 Erweiterungen von Sperrlisten und Sperrlisteneinträgen

In allen Sperrlisten müssen folgende Angaben enthalten sein: • CRL-Nummer (Erweiterung:“CRL Number“). Sie muss für alle von einem Signierer

ausgestellten Sperrlisten eindeutig sein. Für alle Sperrlisten-Einträge müssen folgende Angaben enthalten sein:

• Sperrgrund (Erweiterung: „Reason Code“)

7.3 Profile des Statusabfragedienstes (OCSP)

Ein Statusabfragedienst muss nicht genutzt werden, folglich müssen keine Profile

eingerichtet werden.


Siehe 7.3.


7.3.2 OCSP Erweiterungen

Die OCSP-Erweiterung muss nicht genutzt werden. Siehe auch 7.3.


8 COMPLIANCE-AUDITS UND ANDERE BEWERTUNGEN Es müssen die Regelungen der VW-Group Informationssicherheitsorganisation eingehalten

und damit den Vorstandsanweisungen der Sicherheitsprüfungen zur Regelwerk-Compliance

Folge geleistet werden.

8.1 Häufigkeit und Bedingungen für Audits

Die Häufigkeit der Prüfungen muss sich an der Kritikalität orientieren und ist in den

Handlungsleitlinien festgeschrieben.

8.2 Identität/Qualifikation des Prüfers

Entsprechend Prozess muss der Prüfer durch die IT-Sicherheitsorganisation festgelegt

werden.

8.3 Stellung des Prüfers zum Bewertungsgegenstand

Der Prüfer darf nicht an der Erstellung dieses Dokumentes beteiligt gewesen sein oder

Mitglied der unter [V] genannten Gremien sein. Er soll eine unabhängige Stellung haben.

8.4 Durch Prüfung abzudeckende Themen

Es müssen alle Themen abgedeckt werden, die auch durch die Regelungen der VW-Group

Informationssicherheitsorganisation definiert wurden.

8.5 Reaktionen auf Unzulänglichkeiten

Entsprechend Prozess müssen Unzulänglichkeiten unmittelbar in Zusammenarbeit von

Fachbereich und IT-Sicherheitsorganisation bewertet und Maßnahmen zur Abstellung

getroffen und eingeleitet werden.

8.6 Information über Bewertungsergebnisse

Entsprechend Prozess müssen die Bewertungsergebnisse im Tool ITS-Risk dokumentiert

werden.


9 Sonstige finanzielle und rechtliche Angelegenheiten

9.1 Preise

9.1.1 Preise für Zertifikate oder Zertifikatserneuerungen

Keine Vorgaben, keine Maßnahmen.

9.1.2 Preise für den Zugriff auf Zertifikate


9.1.3 Preise für Sperrungen oder Statusinformationen


9.1.4 Preise für andere Dienstleistungen


9.1.5 Regelungen zur Kostenrückerstattung


9.2 Finanzielle Zuständigkeiten

9.2.1 Versicherungsdeckung


9.2.2 Andere Posten


9.2.3 Versicherung oder Gewährleistung für Endnutzer


9.3 Vertraulichkeit von Geschäftsinformationen

9.3.1 Definition von vertraulichen Informationen

Es müssen die Klassifikations-Kriterien der KSU der Volkswagen AG angewandt werden.


9.3.2 Informationen, die nicht vertraulich behandelt werden

Folgende Information brauchen nicht als vertraulich behandelt werden:

• Zertifikate

• Sperrlisten

• CPs

• CPSs; diese müssen als „intern“ klassifiziert werden.

• Namenskonvention

• Prozessbeschreibungen; diese müssen als „intern“ klassifiziert werden.

• Zertifikatsspezifikationen

9.3.3 Zuständigkeiten für den Schutz vertraulicher Informationen

Die für die Volkswagen Product PKI verantwortlichen Stellen sind für den Schutz der im

Rahmen der jeweiligen CAs anfallenden vertraulichen Informationen zuständig (siehe [V4]).

9.4 Datenschutz von Personendaten

9.4.1 Datenschutzkonzept

Es gelten die jeweils aktuellen datenschutzrechtlichen Gesetze.

9.4.2 Als persönlich behandelte Daten

Innerhalb der Volkswagen AG wird die Fahrgestellnummer (FIN) als personenbezogenes

Datum behandelt. Es gelten die jeweils aktuellen datenschutzrechtlichen Gesetze.

9.4.3 Daten, die nicht als persönlich behandelt werden


9.4.4 Zuständigkeiten für den Datenschutz


9.4.5 Hinweis und Einwilligung zur Nutzung persönlicher Daten

Soweit es sich um persönliche Daten handelt, die im Rahmen administrativer oder anderer

dienstlicher Tätigkeiten protokolliert werden, müssen die Datenschutzregelungen der

Volkswagen AG eingehalten werden.


Da keine Produkt-End-Zertifikate an Personen ausgegeben werden, gibt es zu diesem Punkt

keine Anforderungen.

9.4.6 Auskunft gemäß rechtlicher oder staatlicher Vorschriften

Es muss festgelegt werden, wer entscheidet, ob und wie weit Anfragen von externen Stellen

zu Auskünften beantwortet werden.

Auskunftsverpflichtungen aufgrund lokaler rechtlicher und gesetzlicher Vorgaben bleiben

unberührt.

9.4.7 Andere Bedingungen für Auskünfte

Es muss festgelegt werden, wer entscheidet, ob und wie weit Anfragen von externen Stellen

zu Auskünften beantwortet werden.

9.5 Urheberrechte

Keine Vorgaben. Die Einhaltung von Urheberrechten richtet sich nach den allgemeinen

gesetzlichen Vorschriften.

9.6 Zusicherungen und Garantien

Keine Vorgaben

9.6.1 Zusicherungen und Garantien einer CA

Keine Vorgaben

9.6.2 Zusicherungen und Garantien einer RA

Keine Vorgaben

9.6.3 Zusicherungen und Garantien der Zertifikatsnehmer

Keine Vorgaben

9.6.4 Zusicherungen und Garantien der Zertifikatsnutzer

Keine Vorgaben


9.6.5 Zusicherungen und Garantien anderer Teilnehmer

Keine Vorgaben

9.7 Haftungsausschlüsse

Keine Vorgaben

9.8 Haftungsbeschränkungen

Keine Vorgaben

9.9 Schadensersatz

Keine Vorgaben

9.10 Gültigkeitsdauer des CPS und Beendigung der Gültigkeit

Das CPS zu dieser CP ist gültig ab Freigabe durch die zuständige Stelle [4]. Es ist jeweils

die aktuelle Version des CPS gültig. Das vorangegangene CPS verliert seine Gültigkeit mit

der neueren Version. Mit Ablauf der Gültigkeit dieses CP verliert auch das zugehörige CPS

seine Gültigkeit.

9.11 Individuelle Mitteilungen und Absprachen mit Teilnehmern

Keine Vorgaben

9.12 Änderungen des CPS

Änderungen am CPS zu diesem CP können eingebracht werden von:

- Fachbereich UseCase

- Fachbereich CA

- Coordination Center Product PKI

Änderungen am CPS können nur von der Stelle [4] freigegeben werden, welche für die

Volkswagen Group Product PKI verantwortlich ist.

9.13 Verfahren zur Schlichtung von Streitfällen

Keine Vorgaben


9.14 Zugrundeliegendes Recht

Keine Vorgaben

9.15 Einhaltung geltenden Rechts

Keine Vorgaben

9.16 Sonstige Bestimmungen

9.16.1 Vollständigkeitserklärung

9.16.2 Abgrenzungen

Keine Vorgaben

9.16.3 Salvatorische Klausel

Sollten einzelne Bestimmungen dieser Policy ganz oder teilweise unwirksam oder nichtig

sein oder infolge Änderung der Gesetzeslage oder durch höchstrichterliche Rechtsprechung

oder auf andere Weise ganz oder teilweise unwirksam oder nichtig werden oder weist diese

Policy Lücken auf, so sind sich die Parteien darüber einig, dass die übrigen Bestimmungen

dieser Policy davon unberührt und gültig bleiben. Für diesen Fall verpflichten sich die

Vertragsparteien, unter Berücksichtigung des Grundsatzes von Treu und Glauben an Stelle

der unwirksamen Bestimmung eine wirksame Bestimmung zu vereinbaren, welche dem Sinn

und Zweck der unwirksamen Bestimmung möglichst nahe kommt und von der anzunehmen

ist, dass die Parteien sie im Zeitpunkt des Erstellung der Policy vereinbart hätten, wenn sie

die Unwirksamkeit oder Nichtigkeit gekannt oder vorhergesehen hätten. Entsprechendes gilt,

falls diese Policy eine Lücke enthalten sollte.

9.16.4 Vollstreckung (Anwaltsgebühren und Rechtsmittelverzicht)

Keine Vorgaben

9.16.5 Höhere Gewalt

Keine Vorgaben

9.17 Andere Bestimmungen

Keine Vorgaben

https://www.juraforum.de/lexikon/rechtsprechung

https://www.juraforum.de/lexikon/treu-und-glauben

https://www.juraforum.de/rechtsanwalt/anwalt-stelle/

https://www.juraforum.de/rechtsanwalt/anwalt-sinn/

https://www.juraforum.de/lexikon/nichtigkeit


10 ANHANG

10.1 Quellenverzeichnis

Quelle Dokument

[1] IT-Sicherheitsregelwerk der Volkswagen AG

RdF IT 18

10.2 Anlagen

Das vorliegende Dokument wird durch Anlagen ergänzt, die an gleicher Stelle wie das

vorliegende Dokument publiziert werden müssen und Informationen enthalten, die sich

während des Lebenszyklus des vorliegenden Dokuments erwartungsgemäß ändern werden

(z.B. Dokumentnamen oder Abteilungsbezeichnungen). Änderungen an Anlagen dürfen nur

von der Stelle freigegeben werden, die für die Volkswagen Product PKI verantwortlich ist

(siehe [V4]).

Anlagen Dokument

[A1] Volkswagen_Product_PKI_Root-CP-

Anlage1.docx

Es gilt die jeweils neueste Version der Anlage.

[A2] Volkwagen_Product_PKI_Naming_Convention

s_v<n.n>

Es gilt die jeweils neueste Version der Anlage.

n.n = Version und Release der Anlage.

[A3] Volkswagen Group Product PKI -

Beschreibung der allgemeingültigen

Sperrprozesse in der jeweils gültigen Version


10.3 Verantwortlichkeiten

Soweit in dem vorliegenden Dokument auf Verantwortlichkeiten in Form von [Vn]

hingewiesen wird, sind diese hier aufgeführt.

Verantwortlichkeiten Verantwortliche Stelle

[V1] Für die Freigabe von Änderungen an dieser

CP ist das Coordination Center Product PKI

verantwortlich. Dies muss unter informeller

Einbeziehung des markenübergreifenden „AK

Security“ erfolgen.

[V2] Für die Freigabe eines CPS zu dieser CP ist

das Coordination Center Product PKI

verantwortlich

[V3] Für die Freigabe neuer CA-Typen, deren

Zertifikate unter Anwendung dieser CP erstellt

werden, und neuer CA-Typen, für deren

Betrieb diese CP angewendet werden muss,

ist das Coordination Center Product PKI

verantwortlich.

[V4] In Anlage [A1] wird beschrieben, welche Stelle

für die Volkswagen Group Product PKI

insgesamt und für die zu diesem CP gehörige

CA verantwortlich ist.

Documents

Volkswagen Vehicle Public Key Infrastructure · CP für Root-CA der Product Legacy PKI, P, Serie, Version 1.19 1/77 . Volkswagen Group Product Legacy Public Key Infrastructure - Certificate