DS10 — Le paquet conteneur FES (gcpn.zip)

Déclencheur S4, achèvement de la partie II

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

Manifeste et archive ZIP — deux tâches distinctes

Tâche	Support	Contenu
Manifeste	le `.gcpn.md` lui-même	Liste tous les artefacts avec SHA-256 (table de vérification + artefacts JSON intégrés) — il identifie ce qui fait partie de l'opération
Archive ZIP	`*.gcpn.zip`	Les fichiers physiques pour la livraison : les artefacts textuels (extraits du `.gcpn.md` en `.json`/`.txt`/`.md`/`.gc.md`) plus les artefacts binaires en tant que fichiers séparés

Les artefacts textuels (.json, .txt, .md, .gc.md) vivent dans le .gcpn.md (blocs de code MD) — dans le ZIP, ils apparaissent comme fichiers individuels (extractibles). Les artefacts binaires (PDF, PNG, SVG, …) ne peuvent pas vivre dans le fichier MD — ils sont inclus dans le 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 comme hachage SHA-256 dans les structures de données des artefacts JSON (par 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) + .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)

Lecture : Le manifeste (.gcpn.md) nomme chaque artefact avec SHA-256 — le ZIP fournit les corps correspondants. Les artefacts textuels sont contenus dans le manifeste lui-même (et en plus extraits dans le ZIP sous forme de fichiers individuels) ; les artefacts binaires sont physiquement présents uniquement dans le ZIP, mais 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 dans le 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",
  "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 règle du fac-similé : physiquement pour FES, référence sinon

Important (règle centrale de la saga) :

Procédé	Fac-similé dans le paquet	Justification
Forme textuelle (partie I)	Référence (SHA-256 + estampille guid)	Le graphique se trouve dans le répertoire PII du dépôt du tenant ; la chaîne y fait référence, 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 intentionnelle : pour la forme textuelle, l'actif reste là où il est entretenu de manière pertinente pour 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 ; 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 + la table de vérification sont le manifeste (le dépôt montre le contenu directement ; les fichiers ZIP ne sont pas représentables dans Git)
Comme export	`<Referenced-Doc-Basisname>.gcpn.zip`	Livraison physique (ZIP) — en plus avec `MANIFEST.json` (tous les SHA-256 + `package_sha256`) comme répertoire lisible par machine

La définition du manifeste est-elle donc valable ? Oui — dans les deux formes : dans le dépôt Git, le .gcpn.md remplit la fonction de manifeste (il liste chaque artefact avec 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 plus jointe physiquement sous forme de MANIFEST.json, afin que le destinataire puisse vérifier sans analyseur 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 commerciales regroupées)
`.md`	Basé sur Markdown (artefacts JSON dans des blocs de code MD, compatible Typora) — fonction de manifeste dans le dépôt
`.zip`	Forme d'export (livraison physique, `MANIFEST.json` joint)

La saga clôt la partie II

La boucle est bouclée :

Partie I : chaîne en forme textuelle (document source, document de signature, événements, sidecars, conteneur GCPN) — § 126b BGB, libre appréciation des preuves.
Partie II : arrimage FES (niveaux eIDAS, couche fac-similé, plaque de signature, rapport d'enveloppe, paquet physique).
Partie III (prévue) : cercle PII/GPG — gestion des clés, schémas JSON d'identité de signature, mécanique SSH vs OpenPGP, registre de confiance.

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

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