DS08 — Placa de firma y anclaje de hashes
Desencadenante S4, continuación
El gráfico posicionado (DS07) muestra el dibujo — no lo prueba. La prueba proviene de la placa de firma: el criptograma visible que vincula certificado, hash y marca de tiempo al PDF. E1 pregunta: ¿Cómo queda el gráfico criptográficamente anclado al documento — y cómo sigue siendo verificable de forma nativa en el repo?
Anatomía de la placa de firma
Una placa de firma (Signature Plate, al estilo DocuSign) es un campo visible en el PDF junto al gráfico:
┌──────────────────────────────────────────────┐
│ ____________________________DS │
│ [Facsimile-Grafik, height=40] │
│ Erich Mustermann │
│ Geschäftsführer, handelnd für … │
│ ─────────────────────────────────────────────│
│ ▒ SIGNATURPLATTE (PAdES) │
│ Zertifikat: CN=Erich Mustermann (E1) │
│ SHA-1-Fingerprint: a1b2c3… (angezeigt) │
│ Aussteller: … │
│ Gültigkeit: 2026-09-13 … 2028-09-13 │
│ Dokument-Hash (SHA-256): 3f9a…e21b │
│ Zeitstempel (TSA): 2026-09-13T15:20:00Z │
│ Signatur-Format: PAdES-B-T │
└──────────────────────────────────────────────┘
Los tres anclajes
1. Hash del documento (integridad)
La firma criptográfica (PAdES) se vincula al SHA-256 del contenido del documento PDF (hash de byte-range). Las modificaciones posteriores del PDF invalidan la firma — criterio (b) de eIDAS cumplido.
2. Certificado (atribución de origen)
El certificado de firma vincula la clave de firma a una identidad (CN, unidad organizativa, en su caso cualificado). Criterio (a) de eIDAS cumplido. El certificado se muestra (huella digital, emisor) — un verificador puede leer la identidad sin herramientas criptográficas.
3. Marca de tiempo (temporalidad)
Una marca de tiempo TSA (Trust Service Provider) vincula el momento de la firma a una fuente de tiempo independiente — importante para la Long-Term-Validation (LTV). Las marcas de tiempo uuidV7 en el documento de firma (parte I) siguen siendo las pruebas de tiempo nativas del repo; la TSA es la formal.
La cadena de hashes: documento fuente → documento de firma → PDF
El núcleo del acoplamiento es una cadena de hashes anclada a través de todos los niveles:
sha256 T"] --> B["Signatur-Doc
target.sha256 = T"] B --> C["[FES](../../glossar.html#fes "Fortgeschrittene elektronische Signatur — Glossar")-Dienst
rendert PDF aus Quell-Dokument"] C --> D["PDF (PAdES)
Byte-Range-Hash P"] D --> E["Signaturplatte
zeigt P + Zertifikat + TSA"] B --> F["Envelope-Report (DS09)
sha256(P) = verifiziert"]
Verificación (nativa del repo):
# 1. Quell-Dokument unverändert?
sha256sum source.md # = T
# 2. PDF-Hash stimmt mit Envelope-Report?
sha256sum fes-output.pdf # = P (im Report)
# 3. PDF-Signatur kryptographisch intakt? (externes Tool)
pdfsig fes-output.pdf # VALID, PAdES-B-T
Formato de firma: PAdES
| Formato | Portador | Uso en GitCover |
|---|---|---|
| PAdES | Estándar para procedimientos FES con capa Facsimile (parte II) | |
| XAdES | XML | No típico en el contexto del repo |
| CAdES | genérico | Servicios FES con estructura de envelope propia |
Niveles PAdES (relevantes para la saga):
- B-B/B-T: base + marca de tiempo — nivel típico de salida de DocuSign
- B-LT: Long-Term-Validation (datos de revocación incrustados)
- B-LTA: nivel de archivado (regenerable durante más de 10 años — relevancia para GoBD)
Facsimile y vinculación criptográfica: la distribución de roles
| Nivel | Portador | Función probatoria |
|---|---|---|
| Gráfico visible (Facsimile) | SVG/PNG en la capa | Identificación (§ 126b (3), § 371a ZPO: consignación del nombre) |
| Firma criptográfica | Hash de byte-range PAdES | Integridad (eIDAS (b), (d)) |
| Certificado | Placa de firma | Atribución de origen (eIDAS (a)) |
| Marca de tiempo TSA | Placa de firma | Temporalidad (eIDAS LTV) |
| Cadena del repo | Documento de firma + Events | Documentación del procedimiento, rutina de verificación (DS04) |
Ningún elemento sostiene la prueba por sí solo — la combinación de gráfico, criptografía y cadena del repo es el valor probatorio. Ese es el mensaje central de la saga: GitCover no sustituye a DocuSign, sino que lo ancla.
Manifiesto de verificación
El contenedor GCPN (DS05) recibe un manifiesto verification que agrupa todos los hashes:
{
"verification": {
"ur_doc_sha256": "T",
"signature_doc_sha256": "…",
"events_sha256": ["…", "…"],
"facsimile_sha256": "8fcffe0b…1006",
"facsimile_guid": "01a09b48-4580-76f9-b789-024691b989c5",
"pdf_sha256": "P",
"pdf_signature_format": "PAdES-B-T",
"tsa_timestamp": "2026-09-13T15:20:00Z",
"verified_at": "2026-09-13T16:00:00Z",
"verified_by": "E1"
}
}
Resumen
- La placa de firma muestra certificado, hash del documento, marca de tiempo TSA — visible y legible sin herramientas especiales.
- La cadena de hashes ancla documento fuente → documento de firma → PDF; cada eslabón es verificable por separado.
- PAdES-B-T (con actualización LTV) es el formato FES típico.
- Próximo artículo (DS09): el Envelope-Report — la documentación del expediente al estilo DocuSign en el repo.
Creado: 260913 | Parte II, artículo DS08 | Serie: digital-signage