RFC PV-PACK-001 : ProbatioVault Proof Package Format¶

Statut : Proposition interne Version : 1.0.0 Date : 2026-03-09 Auteur : ProbatioVault Engineering Domaine : Format de conteneur — export probatoire

1. Introduction¶

1.1 Objectif¶

Ce document specifie le format PV Proof Package (.pvproof), le conteneur standard d'export probatoire ProbatioVault. Un fichier .pvproof assemble dans une archive unique et auto-porteur les preuves dechiffrees, les ProofEnvelopes RFC PV-PROOF-001, les metadonnees d'integrite et la documentation de verification.

Le format est concu pour etre remis a un tiers (avocat, OPJ, expert, procureur) sans compte ProbatioVault et sans acces a ProbatioVault. Une partie de la verification peut etre realisee strictement hors ligne (structure, signatures, maillons 1 a 3 de la chaine de preuve). La verification complete de l'ancrage blockchain (maillon 4) peut necessiter l'acces a une source publique independante (noeud, explorer), conformement a RFC PV-PROOF-001 §2.3.

1.2 Portee¶

Ce protocole couvre :

• L'extension de fichier et l'identification du format
• La structure interne de l'archive (repertoires, fichiers obligatoires, fichiers optionnels)
• Le fichier de declaration de format (pvproof.json)
• Le contrat minimal du manifest (manifest.json)
• Les regles de nommage des fichiers
• Les regles de validation d'un conteneur .pvproof (modes strict et tolerant)
• Les contraintes de securite (sanitisation, integrite)

Ce protocole ne couvre PAS :

• Le contenu des ProofEnvelopes (voir RFC PV-PROOF-001)
• Le chiffrement du conteneur lui-meme (hors perimetre V1)
• Le processus d'assemblage cote client (voir story PD-283)
• Le processus de generation des metadonnees cote serveur (voir story PD-85)

1.3 References normatives¶

1.4 Terminologie¶

2. Identification du format¶

2.1 Extension de fichier¶

L'extension OBLIGATOIRE est .pvproof (minuscules).

L'extension .zip est INTERDITE pour un export probatoire ProbatioVault.

2.2 Type MIME (reserve)¶

application/vnd.probatiovault.proof+zip

L'enregistrement IANA est HORS PERIMETRE V1. Le type MIME est reserve pour un usage futur.

2.3 Conteneur technique¶

Le fichier .pvproof est un conteneur ZIP valide conforme a ISO/IEC 21320-1. Tout outil capable de lire un fichier ZIP peut extraire le contenu d'un .pvproof apres renommage de l'extension.

2.4 Magic bytes¶

Le fichier commence par les magic bytes ZIP standard (PK\x03\x04). L'identification du format ProbatioVault repose sur la presence du fichier pvproof.json en premiere entree de l'archive.

3. Format Declaration (pvproof.json)¶

3.1 Position dans l'archive¶

Le fichier pvproof.json DOIT etre la premiere entree (first entry) de l'archive ZIP.

Il DOIT etre ecrit en mode STORED (methode de compression 0, pas de compression).

Cette convention est identique au fichier mimetype dans EPUB OCF 3.3 et permet :

• La detection du format par lecture des premiers octets apres l'en-tete ZIP
• L'identification sans decompression complete de l'archive
• La compatibilite avec les outils de detection de type de fichier

3.2 Schema¶

{
  "format": "ProbatioVault Proof Package",
  "version": "1.0.0",
  "specId": "PV-PACK-001",
  "specVersion": "1.0.0",
  "proofSpecId": "PV-PROOF-001",
  "proofSpecVersion": "1.2.0",
  "createdAt": "<RFC 3339 UTC timestamp>",
  "exportId": "<UUID v4>",
  "proofCount": 3,
  "hashAlgorithm": "SHA3-256",
  "generator": "<identifiant du composant generateur>"
}

3.3 Validation¶

Un fichier pvproof.json est valide si et seulement si :

1. Tous les champs obligatoires sont presents et non vides
2. format vaut exactement "ProbatioVault Proof Package"
3. version est un semver valide
4. specId et specVersion sont des strings non vides
5. proofSpecId et proofSpecVersion sont des strings non vides
6. createdAt est un timestamp RFC 3339 UTC valide
7. exportId est un UUID v4 valide
8. proofCount est un entier >= 1
9. proofCount correspond a manifest.proofCount (coherence inter-fichiers)
10. hashAlgorithm est un algorithme reconnu (V1 : uniquement "SHA3-256")

4. Structure interne de l'archive¶

4.1 Arborescence¶

{nom-fichier}.pvproof
|
+-- pvproof.json                         [OBLIGATOIRE] Declaration de format
+-- manifest.json                        [OBLIGATOIRE] Inventaire + integrityHash
+-- chronology.json                      [OBLIGATOIRE] Evenements probatoires ordonnes
+-- README_VERIFICATION.txt              [OBLIGATOIRE*] Instructions de verification tiers
+-- guide_plainte_france.pdf             [OPTIONNEL]   Guide de procedure juridique (informatif)
+-- preuves/                             [OBLIGATOIRE] Repertoire des fichiers originaux
|   +-- {packageFilename-1}              Fichier original dechiffre
|   +-- {packageFilename-2}
|   +-- ...
+-- enveloppes/                          [OBLIGATOIRE] Repertoire des ProofEnvelopes
    +-- {proofId-1}-envelope.json        ProofEnvelope RFC PV-PROOF-001
    +-- {proofId-2}-envelope.json
    +-- ...

README_VERIFICATION.txt est obligatoire pour la *conformite PV-PACK distribution** (remise a un tiers). Son absence n'invalide pas les mecanismes cryptographiques sous-jacents (integrite manifest, envelopeSeal, chaine de preuve) ; elle invalide uniquement la conformite de distribution PV-PACK en mode strict.

4.2 Fichiers obligatoires¶

4.3 Fichiers optionnels¶

4.4 Repertoires¶

Exactement 2 repertoires au premier niveau :

• preuves/ — contient les fichiers originaux dechiffres
• enveloppes/ — contient les ProofEnvelopes JSON

Aucun sous-repertoire n'est autorise dans preuves/ ou enveloppes/.

5. Contrat minimal du manifest (manifest.json)¶

5.1 Objectif¶

Bien que le contenu detaille du manifest releve de PD-85 (backend), ce RFC impose un contrat minimal pour garantir la coherence structurelle du package. Tout manifest.json inclus dans un .pvproof DOIT contenir au minimum les champs suivants.

5.2 Schema minimal¶

{
  "exportId": "<UUID v4>",
  "exportedAt": "<RFC 3339 UTC>",
  "exportedBy": {
    "userId": "<UUID v4>",
    "role": "USER | LEGAL_GUARDIAN"
  },
  "proofCount": 3,
  "proofs": [
    {
      "proofId": "<UUID v4>",
      "payloadPath": "preuves/{packageFilename}",
      "envelopePath": "enveloppes/{proofId}-envelope.json",
      "originalFilename": "<nom original avant sanitisation>",
      "packageFilename": "<nom apres sanitisation>",
      "payloadHash": "<hex SHA3-256 du fichier original dechiffre>",
      "documentType": "IMAGE | VIDEO | AUDIO | DOCUMENT | MESSAGE | SCREENSHOT | OTHER",
      "sealedAt": "<RFC 3339 UTC>"
    }
  ],
  "integrityHash": "<hex SHA3-256 du manifest canonicalise JCS, hors ce champ>",
  "version": "<semver>"
}

5.3 Champs obligatoires des proof entries¶

5.4 Coherence manifest-archive¶

La validation de coherence repose sur le manifest (source de verite), PAS sur le comptage de fichiers :

1. Pour chaque proof entry dans manifest.proofs[], le fichier payloadPath DOIT exister dans l'archive
2. Pour chaque proof entry dans manifest.proofs[], le fichier envelopePath DOIT exister dans l'archive
3. manifest.proofCount DOIT etre egal a len(manifest.proofs)
4. pvproof.json.proofCount DOIT etre egal a manifest.proofCount
5. L'archive ne DOIT PAS contenir de fichiers dans preuves/ ou enveloppes/ non references par le manifest

Cette approche par mapping explicite (vs. comptage cardinalitaire) permet de gerer les evolutions futures : preuves multi-fichiers, pieces derivees, exports partiels avec documentation des rejets.

5.5 Regles sur les chemins relatifs¶

Les champs payloadPath et envelopePath des proof entries DOIVENT respecter les regles suivantes :

1. payloadPath DOIT commencer par preuves/
2. envelopePath DOIT commencer par enveloppes/
3. Les chemins DOIVENT etre relatifs (pas de prefixe / ou de schema file://)
4. Le separateur de chemin DOIT etre / (slash POSIX), jamais \ (backslash Windows)
5. Les chemins ne DOIVENT PAS contenir de sequences ../ ou ./
6. Les chemins ne DOIVENT PAS contenir de double-slash //

5.6 Unicite des proofId¶

Tous les proofId dans manifest.proofs[] DOIVENT etre uniques. Un manifest contenant deux proof entries avec le meme proofId est invalide.

6. Regles de nommage¶

6.1 Nom du fichier .pvproof¶

Format : PV-Dossier-Plainte_{YYYY-MM-DD}_{exportId-8chars}.pvproof

Exemple complet : PV-Dossier-Plainte_2026-03-09_a1b2c3d4.pvproof

6.2 Noms des fichiers dans preuves/¶

Le nom original du fichier tel que fourni par le backend (originalFilename) est sanitise pour produire le packageFilename (voir §7.2). Le manifest conserve les deux noms pour tracabilite.

6.3 Noms des fichiers dans enveloppes/¶

Format : {proofId}-envelope.json

Le proofId est un UUID v4. Exemple : a1b2c3d4-e5f6-7890-abcd-ef1234567890-envelope.json

7. Securite¶

7.1 Integrite¶

Le fichier manifest.json contient un champ integrityHash (SHA3-256) calcule sur le manifest canonicalise RFC 8785 (JCS), hors le champ integrityHash lui-meme. Ce hash garantit l'integrite du manifest.

Chaque ProofEnvelope contient son propre envelopeSeal (signature HSM ECDSA P-384) garantissant l'integrite de l'enveloppe individuelle.

Chaque proof entry contient un payloadHash (SHA3-256) du fichier dechiffre, permettant a un verificateur de confirmer l'integrite du payload sans recourir a ProbatioVault.

Le hash SHA3-256 du fichier .pvproof complet est informatif (verification de transmission intacte). Il n'est ni scelle ni ancre. La force probante juridique repose sur les ProofEnvelopes individuelles.

7.2 Sanitisation des noms de fichiers (INV-PACK-01)¶

Avant insertion dans l'archive, chaque nom de fichier DOIT etre sanitise :

1. Path traversal : Suppression de toute sequence ../ ou ..\\
2. Caracteres interdits : Suppression de \0, \n, \r, :, *, ?, ", <, >, |, \\
3. Noms reserves : Rejet des noms reserves Windows (CON, PRN, AUX, NUL, COM1-9, LPT1-9)
4. Longueur : Troncature a 200 caracteres (compatible tous OS)
5. Points de debut/fin : Suppression des points en debut et fin de nom
6. Unicite : Si deux fichiers ont le meme nom apres sanitisation, suffixer avec _2, _3, etc.

Le manifest conserve originalFilename (avant) et packageFilename (apres) pour tracabilite et audit.

Violation : Si un nom de fichier ne peut pas etre sanitise (ex: entierement compose de caracteres interdits), le fichier est REJETE avec erreur explicite.

7.3 Immutabilite des artefacts backend (INV-PACK-02)¶

Le client (generateur du package) ne DOIT JAMAIS modifier le contenu des fichiers recus du backend :

• manifest.json — passthrough strict
• chronology.json — passthrough strict
• README_VERIFICATION.txt — passthrough strict
• guide_plainte_france.pdf — passthrough strict
• enveloppes/*.json — passthrough strict

Toute modification invaliderait l'integrityHash du manifest ou l'envelopeSeal des ProofEnvelopes.

7.4 Nettoyage des fichiers temporaires (INV-PACK-03)¶

Pendant l'assemblage du package :

• Les fichiers chiffres telecharges DOIVENT etre supprimes immediatement apres dechiffrement
• Les fichiers dechiffres DOIVENT etre ecrits directement dans le stream ZIP (pas de persistance intermediaire)
• Aucun contenu probatoire en clair ne DOIT persister hors du .pvproof final

7.5 Encodage des fichiers JSON (INV-PACK-08)¶

Tous les fichiers JSON du package (pvproof.json, manifest.json, chronology.json, enveloppes/*.json) DOIVENT etre encodes en UTF-8 sans BOM (Byte Order Mark).

Un fichier JSON commencant par la sequence BOM (EF BB BF) est non conforme.

7.6 Coherence payloadHash et maillon 1 de la chaine de preuve¶

Lorsque le payloadHash (SHA3-256 du fichier dechiffre) est fonctionnellement equivalent au hash documentaire du maillon 1 de la ProofEnvelope (RFC PV-PROOF-001 §2.3 — document hash), les deux valeurs DOIVENT etre coherentes. Si le document exporte est une representation transformee (ex: conversion de format), le payloadHash reflete le fichier exporte et non le hash original du maillon 1 — le manifest DEVRAIT documenter cette distinction dans un champ additionnel en V2.

8. Validation d'un conteneur .pvproof¶

8.1 Modes de validation¶

Le mode de validation DOIT etre declare par l'outil verificateur. Par defaut : strict.

8.2 Niveaux de validation¶

8.3 Regles de validation structurelle¶

Un conteneur .pvproof est structurellement valide si et seulement si :

1. Le fichier a l'extension .pvproof
2. Le contenu est un ZIP valide (magic bytes PK\x03\x04)
3. La premiere entree ZIP est pvproof.json en mode STORED
4. pvproof.json est valide (voir §3.3)
5. manifest.json est present et est du JSON valide
6. chronology.json est present et est du JSON valide
7. README_VERIFICATION.txt est present et non vide (mode strict) ou absent (mode tolerant, warning)
8. Le repertoire preuves/ contient au moins 1 fichier
9. Le repertoire enveloppes/ contient au moins 1 fichier
10. Pour chaque proof entry dans manifest.proofs[], payloadPath existe dans l'archive
11. Pour chaque proof entry dans manifest.proofs[], envelopePath existe dans l'archive
12. L'archive ne contient pas de fichiers dans preuves/ ou enveloppes/ non references par le manifest
13. Aucun repertoire autre que preuves/ et enveloppes/ n'est present au premier niveau (mode strict) ou signale (mode tolerant)
14. Aucun sous-repertoire n'est present dans preuves/ ou enveloppes/

8.4 Erreurs de validation¶

9. Compatibilite et fallback¶

9.1 Instructions pour les tiers¶

Le fichier README_VERIFICATION.txt DOIT inclure la section suivante :

=== FORMAT DU FICHIER ===

Ce fichier porte l'extension .pvproof (ProbatioVault Proof Package).
C'est un conteneur ZIP standard avec une extension dediee.

Si votre ordinateur ne reconnait pas ce format :
1. Renommez le fichier en .zip (ex: dossier.pvproof -> dossier.zip)
2. Extrayez le contenu avec votre outil de decompression habituel
3. Suivez les instructions de verification ci-dessous

9.2 Compatibilite ascendante¶

Le champ version dans pvproof.json permet de gerer les evolutions futures du format :

• Version 1.x.x : ajout de fichiers optionnels (MINOR), corrections (PATCH)
• Version 2.x.x : changement de structure (MAJOR) — un lecteur 1.x ne garantit pas la lecture

Un outil de verification DOIT verifier que la version est compatible avant de proceder a la validation.

10. Invariants du format (non negociables)¶

11. Evolutions prevues¶

Annexe A : Exemple complet¶

PV-Dossier-Plainte_2026-03-09_a1b2c3d4.pvproof
|
+-- pvproof.json
|   {
|     "format": "ProbatioVault Proof Package",
|     "version": "1.0.0",
|     "specId": "PV-PACK-001",
|     "specVersion": "1.0.0",
|     "proofSpecId": "PV-PROOF-001",
|     "proofSpecVersion": "1.2.0",
|     "createdAt": "2026-03-09T14:30:00.000Z",
|     "exportId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
|     "proofCount": 3,
|     "hashAlgorithm": "SHA3-256",
|     "generator": "ProbatioVault-app-ios/1.0.0"
|   }
|
+-- manifest.json
|   {
|     "exportId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
|     "exportedAt": "2026-03-09T14:30:00.000Z",
|     "exportedBy": { "userId": "...", "role": "USER" },
|     "proofCount": 3,
|     "proofs": [
|       {
|         "proofId": "uuid-proof-1",
|         "payloadPath": "preuves/capture-harcelement-01.png",
|         "envelopePath": "enveloppes/uuid-proof-1-envelope.json",
|         "originalFilename": "capture harcelement (01).png",
|         "packageFilename": "capture-harcelement-01.png",
|         "payloadHash": "abc123...",
|         "documentType": "SCREENSHOT",
|         "sealedAt": "2026-02-15T10:00:00.000Z"
|       },
|       { "..." : "..." },
|       { "..." : "..." }
|     ],
|     "integrityHash": "def456...",
|     "version": "1.0.0"
|   }
|
+-- chronology.json              (genere par backend PD-85, passthrough)
+-- README_VERIFICATION.txt      (genere par backend PD-85, passthrough)
+-- guide_plainte_france.pdf     (asset statique backend, informatif, passthrough)
|
+-- preuves/
|   +-- capture-harcelement-01.png
|   +-- conversation-menaces-12.pdf
|   +-- video-preuve-03.mp4
|
+-- enveloppes/
    +-- uuid-proof-1-envelope.json
    +-- uuid-proof-2-envelope.json
    +-- uuid-proof-3-envelope.json

Annexe B : Relation avec les autres RFC¶

+------------------+     reference      +------------------+
| RFC PV-PACK-001  | ----------------> | RFC PV-PROOF-001 |
| (ce document)    |                    | (ProofEnvelope)  |
| Format conteneur |                    | Format preuve    |
+------------------+                    +------------------+
        |                                       |
        | contient N proof entries              | contient
        | (mapping manifest)                    |
        |                                       v
        v                               +------------------+
+------------------+                    | 5 Evidence       |
| .pvproof file    |                    | Sections         |
| (archive ZIP)    |                    | + 4 Chain Links  |
+------------------+                    | + Envelope Seal  |
                                        +------------------+

Le RFC PV-PACK-001 definit le conteneur (comment organiser les fichiers). Le RFC PV-PROOF-001 definit le contenu (ce que chaque ProofEnvelope contient). La coherence entre les deux est assuree par le manifest (source de verite).