PD-39 — Intégration TSA RFC 3161 par Batch Cryptographique (Merkle)¶

1. Objectif¶

Définir de manière formelle, normative, exhaustive et contractuelle les exigences relatives à l’horodatage probatoire des données dans ProbatioVault selon un modèle de batch cryptographique, fondé sur l’horodatage eIDAS qualifié (RFC 3161) d’une empreinte agrégée unique, et le rattachement vérifiable de chaque donnée individuelle par preuve d’inclusion déterministe.

La présente spécification fait loi. Toute implémentation doit s’y conformer strictement.

2. Périmètre / Hors périmètre¶

2.1 Périmètre¶

La spécification couvre exclusivement :

• la constitution d’une empreinte agrégée cryptographiquement définie représentant un ensemble fini de données ;
• la clôture normative d’un batch empêchant toute extension ultérieure ;
• l’émission d’un jeton d’horodatage RFC 3161 par une QTSA qualifiée eIDAS ;
• la validation complète et vérifiable du jeton (signature, chaîne, statut, politique) ;
• la construction et la validation de preuves d’inclusion normativement définies ;
• la conservation probatoire immuable et traçable des éléments.

2.2 Hors périmètre¶

Sont explicitement hors périmètre :

• le choix commercial d’un prestataire QTSA ;
• la stratégie de bascule entre prestataires ;
• la disponibilité, le SLA ou la performance ;
• toute optimisation économique ;
• le renouvellement cryptographique long terme (LTV).

Toute règle relevant de ces éléments est hors périmètre.

3. Définitions¶

4. Invariants (non négociables)¶

1. Tout horodatage probatoire DOIT être émis par une QTSA qualifiée eIDAS, référencée sur une Trusted List officielle.
2. La qualification QTSA DOIT être vérifiée via la policy OID du jeton et la chaîne de certification.
3. Le jeton DOIT être strictement conforme à la RFC 3161.
4. Le jeton DOIT porter sur une empreinte agrégée unique, calculée avec un algorithme explicitement autorisé.
5. Le batch DOIT être déclaré clos avant horodatage ; aucune donnée ne peut y être ajoutée après clôture.
6. L’empreinte agrégée DOIT être construite via une structure d’agrégation déterministe et ordonnée.
7. Chaque donnée DOIT disposer d’une preuve d’inclusion normalisée et vérifiable.
8. Le système NE DOIT PAS utiliser l’heure locale comme référence probatoire.
9. Les validations temporelles DOIVENT s’appuyer sur une horloge de référence définie.
10. Tout élément probatoire accepté NE PEUT être modifié après conservation.

5. Flux nominaux¶

5.1 Constitution et clôture du batch¶

1. Les données candidates sont identifiées.
2. Une structure d’agrégation déterministe est construite à partir de leurs empreintes individuelles.
3. Le batch est clôturé : toute modification ultérieure est interdite.
4. Une empreinte agrégée unique est produite.

5.2 Horodatage¶

1. Une requête RFC 3161 est émise contenant l’empreinte agrégée.
2. La QTSA retourne un jeton d’horodatage signé.

5.3 Validation du jeton¶

1. Conformité RFC 3161 vérifiée.
2. Signature et chaîne de certification validées.
3. Statut de révocation vérifié (CRL/OCSP).
4. Policy OID vérifiée comme autorisée.
5. Cohérence temporelle validée via l’horloge de référence.

5.4 Rattachement individuel¶

1. Pour chaque donnée, une preuve d’inclusion est associée.
2. La preuve complète est constituée par { donnée, preuve d’inclusion, TST }.

5bis. Diagrammes¶

5bis.1 Diagramme d’états — Cycle de vie du batch cryptographique¶

Le batch traverse 4 états principaux. Les transitions sont irréversibles (INV-05 : clôture normative, INV-10 : immutabilité post-conservation).

stateDiagram-v2
    [*] --> OPEN : Création du batch
    OPEN --> CLOSED : Clôture normative (§5.1.3)
    CLOSED --> TIMESTAMPED : TST reçu de la QTSA (§5.2.2)
    TIMESTAMPED --> VALIDATED : Validation complète (§5.3)
    VALIDATED --> [*] : Conservation probatoire

    CLOSED --> REJECTED : Échec horodatage QTSA
    TIMESTAMPED --> REJECTED : Échec validation (signature, CRL, policy OID)
    REJECTED --> [*]

    note right of OPEN
        INV-05 : Aucune donnée ajoutée
        après clôture
    end note

    note right of VALIDATED
        INV-10 : Aucune modification
        après conservation
    end note

5bis.2 Diagramme de séquence — Horodatage batch et rattachement individuel¶

Couvre les flux §5.1 à §5.4. Les validations cryptographiques respectent INV-01 (QTSA qualifiée eIDAS), INV-03 (conformité RFC 3161), INV-06 (structure d’agrégation déterministe) et INV-09 (horloge de référence).

sequenceDiagram
    participant O as Orchestrateur
    participant M as Merkle Tree Builder
    participant Q as QTSA (eIDAS)
    participant V as Token Validator
    participant S as Storage (WORM)

    Note over O,M: §5.1 — Constitution et clôture du batch

    O->>M: Soumettre empreintes individuelles
    M->>M: Construire arbre Merkle (SHA-256, INV-06)
    M->>M: Tri lexicographique + padding puissance de 2
    M-->>O: Empreinte agrégée (root hash)
    O->>O: Clôturer batch (INV-05)

    Note over O,Q: §5.2 — Horodatage RFC 3161

    O->>Q: TimeStampReq (empreinte agrégée, INV-04)
    Q-->>O: TimeStampResp (TST signé, INV-01)

    Note over O,V: §5.3 — Validation du jeton

    O->>V: Valider TST
    V->>V: Vérifier conformité RFC 3161 (INV-03)
    V->>V: Vérifier signature + chaîne (INV-02)
    V->>V: Vérifier révocation CRL/OCSP
    V->>V: Vérifier policy OID (INV-02)
    V->>V: Vérifier cohérence temporelle (INV-08, INV-09)
    V-->>O: Résultat validation

    Note over O,S: §5.4 — Rattachement individuel

    O->>M: Générer preuve d’inclusion par donnée (INV-07)
    M-->>O: { leaf_hash, inclusion_path, root_hash }
    O->>S: Conserver { donnée, preuve inclusion, TST } (INV-10)
    S-->>O: Confirmation conservation WORM

6. Cas d’erreur¶

• QTSA non qualifiée ou policy OID non autorisée.
• Jeton non conforme RFC 3161.
• Signature ou chaîne invalide.
• Révocation ou statut indéterminé.
• Empreinte incohérente.
• Preuve d’inclusion absente ou invalide.
• Tentative d’ajout après clôture.

Tout cas entraîne un rejet explicite et traçable.

7. Critères d’acceptation (testables)¶

• La QTSA figure sur une Trusted List valide.
• Le TST contient une policy OID autorisée.
• L’empreinte agrégée est unique et déterministe.
• Une donnée incluse produit une preuve d’inclusion valide.
• Une donnée non incluse ne peut être rattachée.
• Aucun élément accepté n’est modifiable.

8. Scénarios de test (Given / When / Then)¶

Scénario 1 — Batch clos valide¶

Given un batch clôturé When l’empreinte est horodatée par une QTSA valide Then chaque donnée dispose d’une preuve d’inclusion vérifiable

Scénario 2 — Ajout tardif¶

Given un batch clôturé When une donnée supplémentaire est proposée Then l’opération est rejetée

Scénario 3 — QTSA non qualifiée¶

Given un jeton émis par une TSA non qualifiée When la validation est exécutée Then le jeton est rejeté

9. Hypothèses explicites¶

• Une Trusted List eIDAS est accessible.
• Une horloge de référence est disponible.
• Les mécanismes CRL/OCSP sont accessibles.

Ces hypothèses sont requises mais non garanties par la spécification.

10. Choix cryptographiques (DÉFINITIFS)¶

Référence : CRYPTO-GOV-01 — Politique de choix des algorithmes cryptographiques

10.1 Algorithme de signature du scellement batch¶

Algorithme : ECDSA P-384 (secp384r1) + SHA-384 Niveau de sécurité : ~192 bits

Justification :

Statut : ✅ DÉFINITIF (conformément CRYPTO-GOV-01)

Référence implémentation : tsa.constants.ts

10.2 Algorithme de l'empreinte agrégée (Merkle root)¶

Algorithme : SHA-256 (RFC 6962 Merkle Tree Hash)

Justification :

• Standard Certificate Transparency (CT)
• Compatibilité vérification tierce
• Déterminisme garanti
• Largement reconnu par autorités eIDAS

Statut : ✅ DÉFINITIF

10.3 Format structure d'agrégation¶

Format : RFC 6962 Merkle Tree Hash avec sérialisation CBOR (RFC 8949)

Spécification :

1. Feuilles : SHA-256(0x00 || data)
2. Nœuds : SHA-256(0x01 || left || right)
3. Tri lexicographique des feuilles (déterminisme)
4. Padding puissance de 2 (arbre complet)

Statut : ✅ DÉFINITIF

10.4 Format preuve d'inclusion¶

Format : RFC 9162 InclusionProofDataV2

Champs :

{
  log_id: string;           // Identifiant batch
  tree_size: number;        // Taille arbre Merkle
  leaf_index: number;       // Position feuille
  inclusion_path: string[]; // Chemin audit (hash siblings)
  leaf_hash: string;        // Hash feuille (SHA-256)
  root_hash: string;        // Merkle root (horodaté)
}

Statut : ✅ DÉFINITIF

10.5 Politique de conservation¶

• Rétention minimale : 10 ans (conformité probatoire)
• Format stockage : WORM (Write Once Read Many) recommandé
• Archivage : Conservation jetons TST + preuves inclusion

Statut : ✅ DÉFINITIF

10.6 Policy OID autorisées¶

Source : Extraction automatique depuis Trusted Lists eIDAS (LOTL) Méthode : QtsaQualificationService vérifie ServiceTypeIdentifier "QTimestamp" Registre : qtsa-registry.ts

Statut : ✅ DÉFINI (pas de whitelist manuelle, extraction TL)

11. Gouvernance cryptographique¶

IMPORTANT : PD-39 utilise volontairement ECDSA P-384, distinct de PD-40 (rotation) qui impose Ed25519.

Principe directeur : Les algorithmes cryptographiques sont choisis par fonction probatoire, non par harmonisation technique.

Référence complète : CRYPTO-GOV-01

12. Références normatives¶

• RFC 3161 — Internet X.509 PKI Time-Stamp Protocol (TSP)
• RFC 9162 — Certificate Transparency Version 2.0 (Merkle Tree)
• eIDAS — Règlement (UE) n° 910/2014 sur l'identification électronique
• ETSI TS 119 612 — Trusted Lists (Service Types, Service Status URIs)
• ETSI EN 319 422 — Time-stamping protocol and time-stamp token profiles
• EU LOTL — List of Trusted Lists (Point d'entrée des TL européennes)

13. Limitations connues / Délégations¶

GAP-39-01 — Absence de champ blockchain dans la preuve individuelle¶

Identifié le : 2026-02-17

Description : Le format de preuve individuelle défini à la section 5.4 et en section 10.4 est :

{ donnée, preuve d'inclusion (RFC 9162), TST (RFC 3161) }

Ce format ne contient pas de champ blockchain explicite. Or, en contexte multi-chain (Ethereum L2 primaire, Tezos fallback envisagé dans PD-58), un txid seul est ambigu : un hash Ethereum L2 et un hash d'opération Tezos sont tous deux des chaînes hex indistinguables. Un auditeur ou un tribunal ne peut pas déterminer seul vers quelle blockchain pointer pour valider la transaction.

Impact :

• Le format de preuve doit être étendu avec un champ blockchain: ethereum_l2 | tezos
• PD-58 (Tezos fallback) ne peut pas être implémenté sans cet amendement préalable
• Les preuves existantes (Ethereum L2 uniquement) sont rétrocompatibles par convention : blockchain = ethereum_l2 par défaut

Délégué à : PD-245 — Format de preuve multi-chain

Format amendé cible (défini dans PD-245) :

// Format actuel (section 10.4)
{
  log_id: string;
  tree_size: number;
  leaf_index: number;
  inclusion_path: string[];
  leaf_hash: string;
  root_hash: string;
  // TST RFC 3161 joint
}

// Format amendé (PD-245)
{
  log_id: string;
  tree_size: number;
  leaf_index: number;
  inclusion_path: string[];
  leaf_hash: string;
  root_hash: string;
  blockchain: 'ethereum_l2' | 'tezos';  // NOUVEAU — obligatoire
  // TST RFC 3161 joint
}

Fin de la spécification PD-39 (version batch cryptographique normée).