Part IV — PII, GPG & Governikus (planned)
Status: Planned (DS16–DS21). This part is deliberately separated from the rest of the series — it covers the PII circle (private keys, identity data) and the Git signature mechanics (SSH/OpenPGP), which follow their own compliance rules. New compared to the original planning: The official certification service gpg.governikus.de (BSI-supported) — already discussed in the patent/GBM writings (DPMA research, D15) and in the BSFZ/FZul context — is integrated as a trust anchor.
Why the separation?
Parts I–III cover the document level (source document, signature doc, events, PDF layer, container schema). Part IV covers the key level — and that is a compliance circle of its own:
| Aspect | Parts I–III (document level) | Part IV (key level) |
|---|---|---|
| Data type | Business documents | PII (keys, identity data) |
| Storage location | Tenant repo (Git) | PII directory (gitignored) |
| Directory rule | Git-tracked, sidecar mandatory | Never commit |
| Legal framework | § 126b BGB, § 371a ZPO, eIDAS | DSGVO, GoBD, NIS2, BSI TR-03124 |
| V7GUID classes | SIGNATURE_DOC/EVENT/GRAPHIC | SIGNING_IDENTITY, SIGNING_KEY, GOVERNIKUS_CERT |
Mixing both levels in one article would dilute the PII rule
(Elektronische Unterschrift AD/ and key material never in Git) — hence
the separation.
The trust anchor: gpg.governikus.de
The service gpg.governikus.de (semi-official, commissioned by BSI, operated by
Governikus GmbH & Co. KG) closes the gap that the text form chain (Part I) and
the FES (Part II) leave open: officially secured identity of the key holder.
| Level | Evidence | Cross-reference |
|---|---|---|
| Text form chain | Origin attribution via signature doc + events | Part I (DS02–DS04) |
| FES/ADES | Crypto binding + certificate + facsimile layer | Part II (DS07–DS09) |
| GPG certification | eID authentication (Personalausweis) → name matching → certification of the public key by Governikus (key ID 0x5E5CCCB4A4BF43D7) | Part IV |
| QES | Qualified certificate (EU trust list) | external, docking point (DS06) |
The process flow (6 phases, from the preparatory work 250831 "GitCover® Identity Verification Procedures"):
- Generate GPG key pair (Ed25519 recommended, name exactly as in the Personalausweis)
- eID authentication via
gpg.governikus.de(AusweisApp, NFC/card reader, PIN) - Name matching Personalausweis ↔ GPG key
- Governikus signing of the public key (official certification)
- Integration into the GitCover evidence chains (signature doc
signing_key_ref, Trust Registry) - Registration of the Git hashes (commit signature ↔ certified key)
This results in an officially anchored trust level "high" (BSI TR-03124, eIDAS) below the QES — ideal for the Identity Registry (DS15) and the key binding claims (DS17).
References to patent/GBM writings and BSFZ/FZul
The Governikus flow is already anchored in the writings:
- DPMA research GCEP 260209 (D15): "Governikus GmbH & Co. KG: Services under pgp.governikus.de for PGP certification and qualified electronic signatures" — as prior art against which the GitCover own contribution was delineated.
- BSFZ application GCUCB 2026 (project GitCover.IdP): The certification flow as a component of the evidence chain architecture.
- Preparatory work 250831 (
AIChats/…/GitCover®_Identity_Verification_Procedures): 6-phase procedure, Ed25519 recommendation, AusweisApp integration, Governikus fingerprint864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7.
Part IV concretizes these preparatory works into applicable articles.
Planned articles (DS16–DS21)
| Art. | Title (planned) | Core question | Trigger |
|---|---|---|---|
| DS16 | The signing identity model: identity, signing-keys, authorization | How do we separate declared identity, permissible public key, and the actually signed Git operation? | S5 |
| DS17 | The Trust Registry: PII repo as versioned key source | How are users/*/signing-keys.json deterministically generated into allowed_signers (gpg.ssh.allowedSignersFile)? |
S5 |
| DS18 | Key lifecycle: validity, revocation, supersededBy | How does a historical signature remain valid when the key is rotated? valid-after/valid-before | S5 |
| DS19 | Signed merges: the --no-ff model |
Why is there nothing to sign in a fast-forward merge — and how does the signed release act come about? | S5 |
| DS20 | SSH signature ≠ SSH transport | Why is git commit -S with gpg.format ssh something different from an ssh:// push? signatureScheme vs. transportAuthentication |
S5 |
| DS21 | Official certification: gpg.governikus.de as trust anchor | How do you connect the BSI-supported eID certification of the GPG key to the Identity Registry — 6-phase procedure, name matching, certification signature? | S5 |
The four claims (preparation)
The saga of Part IV will build on four separate claims (from the research 260912, chat "GPG Daten Im JSON Schema"):
- Identity Claim — "Who is this user?"
- Key Binding Claim — "Which public key belonged to this user at that point in time?"
- Authorization Claim — "What was this user allowed to do in this repository?"
- Signature Claim — "Did exactly this key sign exactly this Git object?"
The verification chain: Git Commit → gpgsig → Cryptographic verification → signer key → Key Registry (valid at commit timestamp? revoked?) → Identity Registry (user active?) → Authorization (may commit/merge/release?).
With DS21, the fifth claim is added:
- Attestation Claim — "This identity was officially certified using the eID procedure (Personalausweis, BSI TR-03124)" — the Governikus certification signature on the public key.
Connection to Parts I–III
The signature doc (DS02) has the optional field signing_key_ref — it
remains empty in Parts I–III and is filled in Part IV: The facsimile graphic
(DS07) is the visible feature; the key is the
cryptographic one; the Governikus certification is the official
attestation of key ownership. All three are tied to the same
Identity Registry.
Created: 260913 | Part IV (planned) of the digital-signage series