DS10 — El paquete contenedor FES (gcpn.zip)

Disparador S4, conclusión de la Parte II

El verificador (o socio comercial) quiere ver la cadena — no solo un resumen. No recibe un repo, ni acceso a Git, ni historial. Recibe un paquete: *.gcpn.zip — el conjunto físico de verificación del proceso de firma.

Manifiesto y archivo ZIP — dos tareas separadas

Tarea	Soporte	Contenido
Manifiesto	la propia `.gcpn.md`	Enumera todos los artefactos con SHA-256 (tabla de verificación + artefactos JSON incrustados) — identifica qué pertenece al proceso
Archivo ZIP	`*.gcpn.zip`	Los archivos físicos para la entrega: los artefactos basados en texto (extraídos de la `.gcpn.md` como `.json`/`.txt`/`.md`/`.gc.md`) más los artefactos binarios como archivos separados

Los artefactos basados en texto (.json, .txt, .md, .gc.md) residen en la .gcpn.md (bloques de código MD) — en el ZIP se muestran como archivos individuales (extraíbles). Los artefactos binarios (PDF, PNG, SVG, …) no pueden residir en el archivo MD — se incluyen como archivos separados en el ZIP; por regla general ya están referenciados en las estructuras de datos de los artefactos JSON o identificados como hash SHA-256 (p. ej., evidence.facsimile_ref.sha256) — el hash es la identificación, el ZIP proporciona el cuerpo.

La estructura del paquete

GCPN-SIG-260913-001.gcpn.zip
│
├── container.gcpn.md                      ← Manifest + textbasierte Artefakte (JSON-Fences) + .gc.md
│                                            (identisch mit der Form im Git-Repo)
├── MANIFEST.json                          ← maschinen-lesbares Verzeichnis (alle SHA-256, package_sha256)
│
├── source/                                ← textbasiert: Quell-Dokument, aus dem Container extrahierbar
│   ├── gvb.md                             ← Quell-Dokument (referenced_doc)
│   └── gvb.md.gc.md                      ← Sidecar
├── signature/                             ← textbasiert: Signatur-Doc + Events (aus MD-Fences)
│   ├── signature-doc.json                 ← Signatur-Doc (DS02) + .gc.md
│   ├── event-offered.json                 ← Events (DS03) + .gc.md
│   ├── event-accepted.json
│   ├── event-signed.json
│   ├── facsimile.svg                      ← BINÄR: Grafik physisch (Standard) — im JSON nur als SHA-256 referenziert
│   ├── facsimile.png                      ← BINÄR: Fallback
│   └── facsimile.sha256                   ← Checksums
├── fes/                                   ← binäre FES-Artefakte
│   ├── fes-envelope-report.json           ← Envelope-Report (DS09) + .gc.md (textbasiert)
│   ├── contract-signed.pdf                ← BINÄR: signiertes PDF (PAdES)
│   ├── certificate-of-completion.pdf      ← BINÄR: Dienst-Report
│   └── pdfsig-report.txt                  ← Krypto-Prüfung (externes Tool)
└── README.md                              ← Verifikations-Anleitung (DS04-Routine)

Lectura: El manifiesto (.gcpn.md) nombra cada artefacto con SHA-256 — el ZIP proporciona los cuerpos correspondientes. Los artefactos basados en texto están contenidos en el propio manifiesto (y adicionalmente extraídos como archivos individuales en el ZIP); los artefactos binarios están presentes físicamente solo en el ZIP, pero en el manifiesto están identificados por completo mediante su SHA-256. Por tanto, un verificador puede comprobar cada cuerpo contra el valor hash indicado en el manifiesto.

El manifiesto de verificación

MANIFEST.json reúne todos los SHA-256 del paquete:

{
  "$schema": "https://gitcover.org/schemas/gcpn-manifest-1.0.schema.json",
  "docUid": "<deterministische uuidV7>",
  "package": "GCPN-SIG-260913-001",
  "created_at": "2026-09-13T16:45:00Z",
  "created_by": "E1",
  "artifacts": [
    {"path": "container.md", "sha256": "…"},
    {"path": "source/gvb.md", "sha256": "…"},
    {"path": "signature/signature-doc.json", "sha256": "…"},
    {"path": "signature/event-offered.json", "sha256": "…"},
    {"path": "signature/event-accepted.json", "sha256": "…"},
    {"path": "signature/event-signed.json", "sha256": "…"},
    {"path": "signature/facsimile.svg", "sha256": "8fcffe0b…1006"},
    {"path": "signature/facsimile.png", "sha256": "d330348e…81fef"},
    {"path": "fes/fes-envelope-report.json", "sha256": "…"},
    {"path": "fes/contract-signed.pdf", "sha256": "7a054fa5…272b"}
  ],
  "verification_routine": "siehe README.md (DS04-Routine)",
  "package_sha256": "<SHA-256 des ZIP selbst>"
}

La regla de Facsimile: físico en FES, referencia en los demás casos

Importante (regla central de la saga):

Procedimiento	Facsimile en el paquete	Justificación
Forma textual (Parte I)	Referencia (SHA-256 + sello guid)	El gráfico se encuentra en el directorio PII del repo del tenant; la cadena hace referencia, el paquete documenta la referencia
FES (Parte II)	Físico (SVG + PNG)	El paquete es la entrega completa; el verificador necesita el gráfico para la comprobación, sin acceso al repo

La diferencia es deliberada: en la forma textual, el activo permanece donde se mantiene de forma relevante para GoBD (directorio PII, sidecar, verificación SHA); en FES se copia — el paquete es la versión completa (los originales permanecen sin cambios en el repo; SHA-256 demuestra la identidad).

La rutina de verificación en el paquete

README.md guía al verificador a través de la rutina (DS04, nativa del paquete):

# 1. Manifest-Integrität
sha256sum -c <(jq -r '.artifacts[] | "\(.sha256)  \(.path)"' MANIFEST.json)
# 2. Kette prüfen (Quell-Dokument → Signatur-Doc → Events)
jq -r '.target.sha256' signature/signature-doc.json   # = sha256(source/gvb.md)
# 3. Event-Kette
jq -r '.prev_event_sha256' signature/event-*.json     # Verkettung prüfen
# 4. Facsimile
sha256sum signature/facsimile.svg                     # = 8fcffe0b…1006 (Tabelle)
# 5. PDF-Signatur (externes Tool, optional)
pdfsig fes/contract-signed.pdf                        # VALID, PAdES-B-T

ZIP de exportación vs. repo Git: definición del manifiesto

Dos formas de representación del mismo contenedor:

Forma	Nombre	Función
En el repo Git	`<Referenced-Doc-Basisname>.gcpn.md`	El contenedor mismo — sus artefactos JSON incrustados + la tabla de verificación son el manifiesto (el repo muestra el contenido directamente; los archivos ZIP no son representables en Git)
Como exportación	`<Referenced-Doc-Basisname>.gcpn.zip`	Entrega física (ZIP) — además con `MANIFEST.json` (todos los SHA-256 + `package_sha256`) como directorio legible por máquina

¿Es válida entonces la definición del manifiesto? Sí — en ambas formas: en el repo Git, la .gcpn.md cumple la función de manifiesto (enumera cada artefacto con SHA-256, la rutina de verificación comprueba contra los datos incrustados); en el ZIP de exportación, la misma función de manifiesto se adjunta además físicamente como MANIFEST.json, para que el destinatario pueda comprobar sin un analizador MD (sha256sum -c). Ambas formas son equivalentes — el SHA-256 de los artefactos contenidos es la identificación (siempre y en todas partes).

Sufijo	Significado
`.gcpn`	Contenedor GitCover-PrimaNota (operaciones comerciales agrupadas)
`.md`	Basado en Markdown (artefactos JSON en bloques de código MD, compatible con Typora) — función de manifiesto en el repo
`.zip`	Forma de exportación (entrega física, `MANIFEST.json` adjunto)

La saga cierra la Parte II

El círculo se ha cerrado:

Parte I: cadena de forma textual (documento fuente, documento de firma, eventos, sidecars, contenedor GCPN) — § 126b BGB, libre valoración de la prueba.
Parte II: acoplamiento FES (niveles eIDAS, capa Facsimile, placa de firma, informe de envelope, paquete físico).
Parte III (prevista): círculo PII/GPG — gestión de claves, esquemas JSON de identidad de firma, mecánica SSH vs. OpenPGP, registro de confianza.

La saga muestra: GitCover no sustituye a los servicios de firma — los ancla. El repo sigue siendo el nivel de prueba; los procedimientos externos se acoplan sin romper la cadena.

Creado: 260913 | Parte II, artículo DS10 | Serie: digital-signage