Parte IV — PII, GPG & Governikus (planificada)

Estado: Planificado (DS16–DS21). Esta parte está deliberadamente separada del resto de la serie — trata el ámbito PII (claves privadas, datos de identidad) y la mecánica de firma Git (SSH/OpenPGP), que sigue reglas de cumplimiento propias. Novedad respecto a la planificación original: El servicio oficial de certificación gpg.governikus.de (con apoyo del BSI) — ya tratado en los escritos de patente/GBM (búsqueda DPMA, D15) y en el contexto BSFZ/FZul — se integra como ancla de confianza.

¿Por qué la separación?

Las Partes I–III tratan el nivel de documento (documento fuente, documento de firma, eventos, capa PDF, esquema de contenedor). La Parte IV trata el nivel de claves — y este constituye un ámbito de cumplimiento propio:

Aspecto Partes I–III (nivel de documento) Parte IV (nivel de claves)
Tipo de datos Documentos de negocio PII (claves, datos de identidad)
Ubicación de almacenamiento Tenant-Repo (Git) Directorio PII (gitignored)
Regla de directorio Git-tracked, Sidecar obligatorio Nunca hacer commit
Marco jurídico § 126b BGB, § 371a ZPO, eIDAS DSGVO, GoBD, NIS2, BSI TR-03124
Clases V7GUID SIGNATURE_DOC/EVENT/GRAPHIC SIGNING_IDENTITY, SIGNING_KEY, GOVERNIKUS_CERT

Mezclar ambos niveles en un artículo diluiría la regla PII (Elektronische Unterschrift AD/ y material de claves nunca en Git) — por eso la separación.

El ancla de confianza: gpg.governikus.de

El servicio gpg.governikus.de (semioficial, por encargo del BSI, operado por Governikus GmbH & Co. KG) cierra la brecha que dejan abiertas la cadena de forma textual (Parte I) y la FES (Parte II): identidad oficialmente respaldada del titular de la clave.

Nivel Prueba Referencia cruzada
Cadena de forma textual Asignación de procedencia mediante documento de firma + eventos Parte I (DS02–DS04)
FES/ADES Vinculación criptográfica + certificado + capa de facsímil Parte II (DS07–DS09)
Certificación GPG Autenticación eID (Personalausweis) → cotejo de nombres → certificación de la clave pública por Governikus (ID de clave 0x5E5CCCB4A4BF43D7) Parte IV
QES Certificado cualificado (lista de confianza de la UE) externo, acoplamiento (DS06)

El flujo del procedimiento (6 fases, del trabajo preliminar 250831 „GitCover® Identity Verification Procedures"):

  1. Generar el par de claves GPG (Ed25519 recomendado, nombre exactamente como en el Personalausweis)
  2. Autenticación eID a través de gpg.governikus.de (AusweisApp, NFC/lector de tarjetas, PIN)
  3. Cotejo de nombres Personalausweis ↔ clave GPG
  4. Firma de la clave pública por parte de Governikus (certificación oficial)
  5. Integración en las cadenas de prueba de GitCover (documento de firma signing_key_ref, Trust Registry)
  6. Registro de los hashes de Git (firma del commit ↔ clave certificada)

Con ello se crea un nivel de confianza „alto" anclado oficialmente (BSI TR-03124, eIDAS) por debajo de la QES — ideal para la Identity-Registry (DS15) y los Key-Binding-Claims (DS17).

Referencias a los escritos de patente/GBM y a BSFZ/FZul

El flujo Governikus ya está anclado en los escritos:

La Parte IV concreta estos trabajos preliminares en artículos aplicables.

Artículos planificados (DS16–DS21)

Art. Título (planificado) Pregunta central Desencadenante
DS16 El modelo Signing-Identity: identity, signing-keys, authorization ¿Cómo separamos la identidad declarada, la clave pública permitida y la operación Git realmente firmada? S5
DS17 La Trust Registry: el repo PII como fuente de claves versionada ¿Cómo se generan users/*/signing-keys.json de forma determinista en allowed_signers (gpg.ssh.allowedSignersFile)? S5
DS18 Key-Lifecycle: validity, revocation, supersededBy ¿Cómo sigue siendo válida una firma histórica cuando la clave se rota? valid-after/valid-before S5
DS19 Merges firmados: el modelo --no-ff ¿Por qué un merge fast-forward no tiene nada que firmar — y cómo surge el acto de aprobación firmado? S5
DS20 Firma SSH ≠ transporte SSH ¿Por qué git commit -S con gpg.format ssh es algo distinto de un push ssh://? signatureScheme vs. transportAuthentication S5
DS21 Certificación oficial: gpg.governikus.de como ancla de confianza ¿Cómo se acopla a la Identity-Registry la certificación eID de la clave GPG con apoyo del BSI — procedimiento en 6 fases, cotejo de nombres, firma de certificación? S5

Los cuatro Claims (preparación)

La saga de la Parte IV se construirá sobre cuatro Claims separados (de la búsqueda 260912, chat „GPG Daten Im JSON Schema"):

  1. Identity Claim — "¿Quién es este usuario?"
  2. Key Binding Claim — "¿Qué clave pública pertenecía a este usuario en ese momento?"
  3. Authorization Claim — "¿Qué podía hacer este usuario en este repositorio?"
  4. Signature Claim — "¿Firmó exactamente esta clave exactamente este objeto Git?"

La cadena de verificación: Git Commit → gpgsig → Cryptographic verification → signer key → Key Registry (valid at commit timestamp? revoked?) → Identity Registry (user active?) → Authorization (may commit/merge/release?).

Con DS21 se añade el quinto Claim:

  1. Attestation Claim — "Esta identidad fue certificada oficialmente mediante el procedimiento eID (Personalausweis, BSI TR-03124)" — la firma de certificación de Governikus sobre la clave pública.

Enlace con las Partes I–III

El documento de firma (DS02) tiene el campo opcional signing_key_ref — permanece vacío en las Partes I–III y se completa en la Parte IV: El gráfico de facsímil (DS07) es el rasgo visible; la clave, el criptográfico; la certificación Governikus, la constancia oficial de la posesión de la clave. Los tres están anclados a la misma Identity-Registry.


Creado: 260913 | Parte IV (planificada) de la serie digital-signage