Teil IV — PII, GPG & Governikus (geplant)
Status: Geplant (DS16–DS21). Dieser Teil ist bewusst vom Rest der Serie abgetrennt — er behandelt den PII-Kreis (private Schlüssel, Identity-Daten) und die Git-Signatur-Mechanik (SSH/OpenPGP), die eigenen Compliance-Regeln folgt. Neu gegenüber der ursprünglichen Planung: Der amtliche Beglaubigungs-Dienst gpg.governikus.de (BSI-unterstützt) — bereits in den Patent-/GBM-Schriften (DPMA-Recherche, D15) und im BSFZ/FZul-Kontext besprochen — wird als Vertrauensanker integriert.
Warum die Trennung?
Teil I–III behandeln die Dokument-Ebene (Quell-Dokument, Signatur-Doc, Events, PDF-Layer, Container-Schema). Teil IV behandelt die Schlüssel-Ebene — und die ist ein eigener Compliance-Kreis:
| Aspekt | Teil I–III (Dokument-Ebene) | Teil IV (Schlüssel-Ebene) |
|---|---|---|
| Datenart | Geschäfts-Dokumente | PII (Schlüssel, Identity-Daten) |
| Lagerort | Tenant-Repo (Git) | PII-Verzeichnis (gitignored) |
| Verzeichnis-Regel | Git-tracked, Sidecar-pflichtig | Niemals committen |
| Rechtsrahmen | § 126b BGB, § 371a ZPO, eIDAS | DSGVO, GoBD, NIS2, BSI TR-03124 |
| V7GUID-Classes | SIGNATURE_DOC/EVENT/GRAPHIC | SIGNING_IDENTITY, SIGNING_KEY, GOVERNIKUS_CERT |
Das Mischen beider Ebenen in einem Artikel würde die PII-Regel
(Elektronische Unterschrift AD/ und Schlüssel-Material niemals in Git)
verwässern — deshalb die Trennung.
Der Vertrauensanker: gpg.governikus.de
Der Dienst gpg.governikus.de (halbamtl., BSI-auftraggebend, von der
Governikus GmbH & Co. KG betrieben) schließt die Lücke, die die Textform-
Kette (Teil I) und die FES (Teil II) offen lassen: amtlich abgesicherte
Identität des Schlüsselinhabers.
| Ebene | Nachweis | Querverweis |
|---|---|---|
| Textform-Kette | Herkunfts-Zuordnung über Signatur-Doc + Events | Teil I (DS02–DS04) |
| FES/ADES | Kryptobindung + Zertifikat + Facsimile-Layer | Teil II (DS07–DS09) |
| GPG-Beglaubigung | eID-Authentisierung (Personalausweis) → Namensabgleich → Beglaubigung des Public Keys durch Governikus (Schlüssel-ID 0x5E5CCCB4A4BF43D7) | Teil IV |
| QES | Qualifiziertes Zertifikat (EU-Trust-Liste) | extern, Andock (DS06) |
Der Verfahrensfluss (6 Phasen, aus der Vorarbeit 250831 „GitCover® Identity Verification Procedures"):
- GPG-Schlüsselpaar generieren (Ed25519 empfohlen, Name exakt wie im Personalausweis)
- eID-Authentisierung über
gpg.governikus.de(AusweisApp, NFC/Kartenleser, PIN) - Namensabgleich Personalausweis ↔ GPG-Schlüssel
- Governikus-Signierung des öffentlichen Schlüssels (amtliche Beglaubigung)
- Integration in die GitCover-Beweisketten (Signatur-Doc
signing_key_ref, Trust Registry) - Registrierung der Git-Hashes (Commit-Signatur ↔ beglaubigter Schlüssel)
Damit entsteht ein amtlich verankertes Vertrauensniveau „hoch" (BSI TR-03124, eIDAS) unterhalb der QES — ideal für die Identity-Registry (DS15) und die Key-Binding-Claims (DS17).
Bezüge zu Patent-/GBM-Schriften und BSFZ/FZul
Der Governikus-Fluss ist bereits in den Schriften verankert:
- DPMA-Recherche GCEP 260209 (D15): „Governikus GmbH & Co. KG: Dienste unter pgp.governikus.de für PGP-Beglaubigung und qualifizierte elektronische Signaturen" — als Stand der Technik, gegen den die GitCover-Eigenleistung abgegrenzt wurde.
- BSFZ-Antrag GCUCB 2026 (Vorhaben GitCover.IdP): Der Beglaubigungsfluss als Komponente der Beweisketten-Architektur.
- Vorarbeit 250831 (
AIChats/…/GitCover®_Identity_Verification_Procedures): 6-Phasen-Verfahren, Ed25519-Empfehlung, AusweisApp-Integration, Governikus-Fingerprint864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7.
Teil IV konkretisiert diese Vorarbeiten zu anwendbaren Artikeln.
Geplante Artikel (DS16–DS21)
| Art. | Titel (geplant) | Kernfrage | Auslöser |
|---|---|---|---|
| DS16 | Das Signing-Identity-Modell: identity, signing-keys, authorization | Wie trennen wir deklarierte Identität, zulässigen Public Key und tatsächlich signierte Git-Operation? | S5 |
| DS17 | Die Trust Registry: PII-Repo als versionierte Schlüsselquelle | Wie werden users/*/signing-keys.json deterministisch zu allowed_signers generiert (gpg.ssh.allowedSignersFile)? |
S5 |
| DS18 | Key-Lifecycle: validity, revocation, supersededBy | Wie bleibt eine historische Signatur gültig, wenn der Schlüssel rotiert? valid-after/valid-before | S5 |
| DS19 | Signierte Merges: das --no-ff-Modell |
Warum ist ein Fast-Forward-Merge nichts zu signieren — und wie entsteht der signierte Freigabeakt? | S5 |
| DS20 | SSH-Signatur ≠ SSH-Transport | Warum ist git commit -S mit gpg.format ssh etwas anderes als ssh://-Push? signatureScheme vs. transportAuthentication |
S5 |
| DS21 | Amtliche Beglaubigung: gpg.governikus.de als Vertrauensanker | Wie dockt man die BSI-unterstützte eID-Beglaubigung des GPG-Schlüssels an die Identity-Registry an — 6-Phasen-Verfahren, Namensabgleich, Beglaubigungs-Signatur? | S5 |
Die vier Claims (Vorbereitung)
Die Saga von Teil IV wird auf vier getrennte Claims aufbauen (aus der Recherche 260912, Chat „GPG Daten Im JSON Schema"):
- Identity Claim — "Wer ist dieser Benutzer?"
- Key Binding Claim — "Welcher Public Key gehörte diesem Benutzer zu diesem Zeitpunkt?"
- Authorization Claim — "Was durfte dieser Benutzer in diesem Repository tun?"
- Signature Claim — "Hat genau dieser Key genau dieses Git-Objekt signiert?"
Die Prüf-Kette: Git Commit → gpgsig → Cryptographic verification → signer key → Key Registry (valid at commit timestamp? revoked?) → Identity Registry (user active?) → Authorization (may commit/merge/release?).
Mit DS21 kommt der fünfte Claim hinzu:
- Attestation Claim — "Diese Identität wurde mit dem eID-Verfahren (Personalausweis, BSI TR-03124) amtlich beglaubigt" — der Governikus-Beglaubigungs-Signatur auf dem Public Key.
Verknüpfung zu Teil I–III
Der Signatur-Doc (DS02) hat das optionale Feld signing_key_ref — es
bleibt in Teil I–III leer und wird in Teil IV belegt: Die Facsimile-Grafik
(DS07) ist das sichtbare Merkmal; der Schlüssel ist das
kryptographische; die Governikus-Beglaubigung ist das amtliche
Attest für den Schlüssel-Besitz. Alle drei hängen an derselben
Identity-Registry.
Erstellt: 260913 | Teil IV (geplant) der Serie digital-signage