GitCover Symbol GCBoKGitCover Body of Knowledge

Partie IV — PII, GPG & Governikus (planifiée)

Statut : Planifiée (DS16–DS21). Cette partie est volontairement détachée du reste de la série — elle traite du périmètre PII (clés privées, données d'identité) et de la mécanique de signature Git (SSH/OpenPGP), qui suit ses propres règles de conformité. Nouveauté par rapport à la planification initiale : le service de certification officiel gpg.governikus.de (soutenu par le BSI) — déjà abordé dans les écrits de brevet/GBM (recherche DPMA, D15) et dans le contexte BSFZ/FZul — est intégré comme ancre de confiance.

Pourquoi cette séparation ?

Les parties I–III traitent de la couche document (document source, Signatur-Doc, Events, PDF-Layer, Container-Schema). La partie IV traite de la couche des clés — et celle-ci constitue un périmètre de conformité à part entière :

Aspect Parties I–III (couche document) Partie IV (couche des clés)
Type de données Documents d'affaires PII (clés, données d'identité)
Lieu de stockage Tenant-Repo (Git) Répertoire PII (gitignored)
Règle de répertoire Git-tracked, Sidecar-pflichtig Ne jamais committer
Cadre juridique § 126b BGB, § 371a ZPO, eIDAS DSGVO, GoBD, NIS2, BSI TR-03124
Classes V7GUID SIGNATURE_DOC/EVENT/GRAPHIC SIGNING_IDENTITY, SIGNING_KEY, GOVERNIKUS_CERT

Mélanger les deux couches dans un même article diluerait la règle PII (Elektronische Unterschrift AD/ et matériel de clés jamais dans Git) — d'où la séparation.

L'ancre de confiance : gpg.governikus.de

Le service gpg.governikus.de (semi-officiel, dont le BSI est le donneur d'ordre, exploité par la Governikus GmbH & Co. KG) comble la lacune que la chaîne de forme textuelle (partie I) et la FES (partie II) laissent ouverte : l'identité officiellement sécurisée du détenteur de la clé.

Niveau Preuve Référence croisée
Chaîne de forme textuelle Attribution d'origine via Signatur-Doc + Events Partie I (DS02–DS04)
FES/ADES Liaison cryptographique + certificat + Facsimile-Layer Partie II (DS07–DS09)
Certification GPG Authentification eID (Personalausweis) → comparaison des noms → certification de la clé publique par Governikus (ID de clé 0x5E5CCCB4A4BF43D7) Partie IV
QES Certificat qualifié (EU-Trust-Liste) externe, raccordement (DS06)

Le flux de procédure (6 phases, issu des travaux préliminaires 250831 « GitCover® Identity Verification Procedures ») :

  1. Générer la paire de clés GPG (Ed25519 recommandé, nom exactement comme sur le Personalausweis)
  2. Authentification eID via gpg.governikus.de (AusweisApp, NFC/lecteur de cartes, PIN)
  3. Comparaison des noms Personalausweis ↔ clé GPG
  4. Signature de la clé publique par Governikus (certification officielle)
  5. Intégration dans les chaînes de preuve GitCover (Signatur-Doc signing_key_ref, Trust Registry)
  6. Enregistrement des hachages Git (signature de commit ↔ clé certifiée)

Il en résulte un niveau de confiance « élevé » ancré officiellement (BSI TR-03124, eIDAS) en dessous de la QES — idéal pour l' Identity-Registry (DS15) et les Key-Binding-Claims (DS17).

Références aux écrits de brevet/GBM et au BSFZ/FZul

Le flux Governikus est déjà ancré dans les écrits :

La partie IV concrétise ces travaux préliminaires en articles applicables.

Articles planifiés (DS16–DS21)

Art. Titre (planifié) Question centrale Déclencheur
DS16 Le modèle Signing-Identity : identity, signing-keys, authorization Comment distinguons-nous l'identité déclarée, la clé publique autorisée et l'opération Git réellement signée ? S5
DS17 La Trust Registry : le dépôt PII comme source de clés versionnée Comment génère-t-on users/*/signing-keys.json de manière déterministe en allowed_signers (gpg.ssh.allowedSignersFile) ? S5
DS18 Cycle de vie des clés : validity, revocation, supersededBy Comment une signature historique reste-t-elle valide lors de la rotation de la clé ? valid-after/valid-before S5
DS19 Merges signés : le modèle --no-ff Pourquoi un merge fast-forward n'a-t-il rien à signer — et comment naît l'acte de validation signé ? S5
DS20 Signature SSH ≠ transport SSH Pourquoi git commit -S avec gpg.format ssh est-il autre chose qu'un push ssh:// ? signatureScheme vs. transportAuthentication S5
DS21 Certification officielle : gpg.governikus.de comme ancre de confiance Comment raccorde-t-on la certification eID de la clé GPG soutenue par le BSI à l'Identity-Registry — procédure en 6 phases, comparaison des noms, signature de certification ? S5

Les quatre Claims (préparation)

La saga de la partie IV s'appuiera sur quatre Claims distincts (issus de la recherche 260912, chat « GPG Daten Im JSON Schema ») :

  1. Identity Claim — « Qui est cet utilisateur ? »
  2. Key Binding Claim — « Quelle clé publique appartenait à cet utilisateur à ce moment-là ? »
  3. Authorization Claim — « Que cet utilisateur était-il autorisé à faire dans ce dépôt ? »
  4. Signature Claim — « Exactement cette clé a-t-elle signé exactement cet objet Git ? »

La chaîne de vérification : Git Commit → gpgsig → Cryptographic verification → signer key → Key Registry (valid at commit timestamp? revoked?) → Identity Registry (user active?) → Authorization (may commit/merge/release?).

Avec la DS21 s'ajoute le cinquième Claim :

  1. Attestation Claim — « Cette identité a été certifiée officiellement par la procédure eID (Personalausweis, BSI TR-03124) » — la signature de certification Governikus sur la clé publique.

Lien avec les parties I–III

Le Signatur-Doc (DS02) comporte le champ optionnel signing_key_ref — il reste vide dans les parties I–III et est renseigné dans la partie IV : le graphique Facsimile (DS07) est le signe visible ; la clé est le signe cryptographique ; la certification Governikus est l'attestation officielle de la possession de la clé. Les trois se rattachent à la même Identity-Registry.

Créé : 260913 | Partie IV (planifiée) de la série digital-signage