DS10 — Le paquet conteneur FES (gcpn.zip)

Déclencheur S4, conclusion de la partie II

Le vérificateur (ou partenaire commercial) veut voir la chaîne — pas seulement sous forme résumée. Il ne reçoit ni dépôt, ni accès Git, ni historique. Il reçoit un paquet : *.gcpn.zip — l'ensemble de vérification physique du processus de signature.

Manifeste et archive ZIP — deux tâches distinctes

Tâche	Support	Contenu
Manifeste	la `.gcpn.md` elle-même	Répertorie tous les artefacts avec leur SHA-256 (tableau de vérification + artefacts JSON intégrés) — elle identifie ce qui appartient au processus
Archive ZIP	`*.gcpn.zip`	Les fichiers physiques à livrer : les artefacts textuels (extraits de la `.gcpn.md` sous forme de `.json`/`.txt`/`.md`/`.v7g.md`) plus les artefacts binaires en tant que fichiers séparés

Les artefacts textuels (.json, .txt, .md, .v7g.md) vivent dans la .gcpn.md (MD-Fences) — dans le ZIP, ils sont présentés comme fichiers individuels (extractibles). Les artefacts binaires (PDF, PNG, SVG, …) ne peuvent pas vivre dans le fichier MD — ils sont ajoutés au ZIP en tant que fichiers séparés ; en règle générale, ils sont déjà référencés ou identifiés en tant que hachage SHA-256 dans les structures de données des artefacts JSON (p. ex. evidence.facsimile_ref.sha256) — le hachage est l'identification, le ZIP fournit le corps.

La structure du paquet

GCPN-SIG-260913-001.gcpn.zip
│
├── container.gcpn.md                      ← Manifest + textbasierte Artefakte (JSON-Fences) + .v7g.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.v7g.md                      ← Sidecar
├── signature/                             ← textbasiert: Signatur-Doc + Events (aus MD-Fences)
│   ├── signature-doc.json                 ← Signatur-Doc (DS02) + .v7g.md
│   ├── event-offered.json                 ← Events (DS03) + .v7g.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) + .v7g.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)

Lecture : le manifeste (.gcpn.md) nomme chaque artefact avec son SHA-256 — le ZIP fournit les corps correspondants. Les artefacts textuels sont contenus dans le manifeste lui-même (et dans le ZIP en outre extraits comme fichiers individuels) ; les artefacts binaires existent physiquement uniquement dans le ZIP, mais sont dans le manifeste entièrement identifiés par leur SHA-256. Un vérificateur peut donc vérifier chaque corps par rapport à l'indication de hachage du manifeste.

Le manifeste de vérification

MANIFEST.json regroupe tous les SHA-256 du paquet :

{
  "$schema": "https://gitcover.org/schemas/gcpn-manifest-1.0.schema.json",
  "uuidV7": "<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 règle Facsimile : physique pour FES, référence sinon

Important (règle centrale de la Saga) :

Procédure	Facsimile dans le paquet	Justification
Forme textuelle (partie I)	Référence (SHA-256 + tampon guid)	Le graphique se trouve dans le répertoire PII du dépôt du tenant ; la chaîne y renvoie, le paquet documente la référence
FES (partie II)	Physique (SVG + PNG)	Le paquet est la livraison complète ; le vérificateur a besoin du graphique pour la vérification, sans accès au dépôt

La différence est délibérée : dans le cas de la forme textuelle, l'actif reste là où il est géré de manière pertinente pour la GoBD (répertoire PII, Sidecar, vérification SHA) ; pour la FES, il est copié — le paquet est la version complète (les originaux restent inchangés dans le dépôt ; le SHA-256 prouve l'identité).

La routine de vérification dans le paquet

README.md guide le vérificateur à travers la routine (DS04, native au paquet) :

# 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 d'export vs. dépôt Git : définition du manifeste

Deux formes de représentation du même conteneur :

Forme	Nom	Rôle
Dans le dépôt Git	`<Referenced-Doc-Basisname>.gcpn.md`	Le conteneur lui-même — ses artefacts JSON intégrés + tableau de vérification constituent le manifeste (le dépôt montre le contenu directement ; les fichiers ZIP ne sont pas représentables dans Git)
En tant qu'export	`<Referenced-Doc-Basisname>.gcpn.zip`	Livraison physique (ZIP) — en outre avec `MANIFEST.json` (tous les SHA-256 + `package_sha256`) comme répertoire lisible par machine

La définition du manifeste est-elle ainsi valide ? Oui — dans les deux formes : dans le dépôt Git, la .gcpn.md remplit la fonction de manifeste (elle répertorie chaque artefact avec son SHA-256, la routine de vérification contrôle par rapport aux indications intégrées) ; dans le ZIP d'export, la même fonction de manifeste est en outre jointe physiquement en tant que MANIFEST.json, afin que le destinataire puisse vérifier sans parseur MD (sha256sum -c). Les deux formes sont équivalentes — le SHA-256 des artefacts contenus est l'identification (toujours et partout).

Suffixe	Signification
`.gcpn`	Conteneur GitCover-PrimaNota (opérations regroupées)
`.md`	Basé sur Markdown (artefacts JSON dans des MD-Fences, compatible Typora) — fonction de manifeste dans le dépôt
`.zip`	Forme d'export (livraison physique, `MANIFEST.json` joint)

La Saga conclut la partie II

Le cercle est bouclé :

Partie I : chaîne de forme textuelle (document source, document de signature, événements, sidecars, conteneur GCPN) — § 126b BGB, libre appréciation des preuves.
Partie II : raccordement FES (niveaux eIDAS, couche Facsimile, plaque de signature, Envelope-Report, paquet physique).
Partie III (prévue) : cercle PII/GPG — gestion des clés, schémas JSON Signing-Identity, mécanique SSH vs. OpenPGP, Trust-Registry.

La Saga montre : GitCover ne remplace pas les services de signature — il les ancre. Le dépôt reste la couche de preuve ; les procédures externes s'y raccordent sans briser la chaîne.

Créé : 260913 | Partie II, article DS10 | Série : digital-signage