PD-282 - ProofEnvelope auto-verifiable : scellement HSM global et materiel eIDAS/OCSP embarque¶

1. Objectif¶

La User Story PD-282 contractualise la production d'une ProofEnvelope auto-verifiable par un tiers, sans dependance aux services ProbatioVault, via :

• un scellement cryptographique global de l'enveloppe (envelopeSeal) couvrant l'integralite du contenu canonicalise (JCS RFC 8785) ;
• l'inclusion d'un materiel de verification offline (verificationMaterial) comprenant chaines de certificats et snapshots OCSP au moment de generation ;
• la garantie qu'une modification d'un octet invalide la verification ;
• la compatibilite avec l'immutabilite persistee (PD-272) et le modele d'etats de reference (PD-280), sans contournement des invariants existants.

2. Perimetre / Hors perimetre¶

Inclus¶

• Generation d'un champ envelopeSeal pour chaque enveloppe finalisee.
• Couverture de signature sur l'enveloppe complete hors champ envelopeSeal.
• Inclusion de verificationMaterial avec tsaCertificateChain, eidasCertificateChain, ocspResponses, validationTimestamp, validationPolicy.
• Verification tierce en mode offline strict (air-gapped) et mode online public (sans service ProbatioVault).
• Compatibilite de verification apres rotation de cle via kid + chaine de certificats embarquee.
• Regles de rejet explicites en cas de format invalide ou donnees manquantes.

Exclu¶

• Outil CLI public package (hors script de preuve interne).
• Evolution UI/front.
• Refonte du mecanisme d'ancrage blockchain existant.
• Processus de revocation de cles HSM compromises.
• Migration vers formats CAdES/XAdES/PAdES.
• LTV (re-horodatage periodique long terme ETSI).
• Changement de schema d'etat global si PD-280 non disponible (compatibilite API uniquement).

3. Definitions¶

• ProofEnvelope : structure JSON probante contenant preuves cryptographiques et metadonnees.
• JCS : JSON Canonicalization Scheme (RFC 8785), serialisation deterministe.
• envelopeSeal : sceau global HSM de l'enveloppe.
• verificationMaterial : materiaux cryptographiques necessaires a la verification autonome.
• GENERATION_TIME_SNAPSHOT : politique attestant l'etat de non-revocation au moment T de generation.
• Mode A : verification offline stricte sans reseau.
• Mode B : verification online publique (blockchain/OCSP/CRL publics), sans dependance ProbatioVault.
• Etat terminal : etat sans transition sortante autorisee.
• Token TSA (RFC 3161) : produit par PD-81 (LegalCompositeProof) et partie integrante de la ProofEnvelope. tsaCertificateChain permet la verification de ce token TSA existant.

4. Invariants (non negociables)¶

5. Flux nominaux¶

5.1 Modele de donnees contractuel (format unique de reference)¶

5.1.1 envelopeSeal¶

5.1.2 verificationMaterial¶

Regle de normalisation certSerialNumber : la normalisation uppercase est appliquee a l'ingestion (avant stockage). Toute comparaison se fait sur la forme normalisee.

Regle d'unicite de definition : les formats ci-dessus sont la reference unique ; toute autre section s'y refere sans redefinition.

5.2 Parametres numeriques contractuels¶

5.3 SLA temporels¶

• Aucune transition temporelle metier de type TTL/expiration/delai de validite d'etat n'est introduite par PD-282.
• Les horodatages signedAt, producedAt, validationTimestamp sont des preuves temporelles, pas des timers d'expiration d'etat.
• Mention obligatoire : Aucune transition temporelle identifiee.

5.4 Machine d'etats UNSEALED/SEALED¶

• UNSEALED est un etat transitoire en memoire au niveau service; il n'est jamais persiste dans legal_composite_proof.
• La persistance est atomique en INSERT direct SEALED (payload complet incluant envelope_seal), sans sequence INSERT puis UPDATE.
• La testabilite de la transition UNSEALED -> SEALED est portee par les tests service (unitaires) sur la construction en memoire et la validation du payload final.
• La base de donnees ne teste pas une transition UNSEALED -> SEALED par UPDATE, car ce chemin n'existe pas par design.
• Justification architecturale: le trigger d'immutabilite PD-272 bloque tout UPDATE sur legal_composite_proof; le pattern INSERT-only est donc la seule option compatible sans modifier ce trigger.

5.5 Atomicite multi-composant¶

• INSERT/UPDATE base probatoire : synchrone transactionnel (ACID).
• Verifications asynchrones externes eventuelles (hors transaction DB) : idempotentes et retry-safe.
• Crash pre-commit : rollback total, aucun artefact persistant.
• Crash post-commit : etat DB autoritatif, rattrapage asynchrone par mecanisme de reconciliation existant.
• Aucun contournement d'immutabilite autorise.

5.6 Strategie de migration DDL¶

5.7 Contraintes inter-modules¶

• Aucune route d'un autre module n'est explicitement protegee/modifiee par cette story.
• Le token TSA (RFC 3161) est produit par PD-81 (LegalCompositeProof) et fait partie integrante de la ProofEnvelope.
• tsaCertificateChain est requis pour verifier ce token TSA existant.
• Mention obligatoire : Aucune contrainte inter-module de routage applicable.

5bis. Diagrammes¶

5bis.1 Machine d'etats UNSEALED / SEALED¶

stateDiagram-v2
    direction LR

    state "UNSEALED\n(transitoire memoire)" as UNSEALED
    state "SEALED\n(persiste, terminal)" as SEALED

    [*] --> UNSEALED : Construction en memoire

    UNSEALED --> SEALED : INSERT atomique\n(payload complet + envelopeSeal)

    SEALED --> [*]

    note right of SEALED
        Etat terminal (INV-282-09)
        Aucune transition sortante autorisee
        UPDATE/DELETE interdit (trigger PD-272)
    end note

    note left of UNSEALED
        Jamais persiste en base
        Etat transitoire service uniquement
    end note

Transitions interdites (INV-282-09, INV-282-10) :

5bis.2 Flux de scellement (generation de l'enveloppe)¶

sequenceDiagram
    participant S as ProofEnvelopeService
    participant V as ValidationService
    participant OCSP as Repondeur OCSP
    participant HSM as CloudHSM (PKCS#11)
    participant DB as PostgreSQL<br/>(legal_composite_proof)

    Note over S: Etat UNSEALED (memoire)

    S->>S: Assembler ProofEnvelope<br/>(preuves + metadonnees)
    S->>S: Scan heuristique anti-secrets<br/>(INV-282-06 : patterns interdits)
    alt Pattern interdit detecte
        S-->>S: REJET finalisation (ERR-06)
    end

    S->>V: Demander verificationMaterial
    V->>OCSP: Requete OCSP par certificat<br/>(timeout contractuel <= 10000ms)
    alt OCSP disponible
        OCSP-->>V: OCSPResponse (status: good/revoked/unknown)
        alt status = revoked
            V-->>S: REJET finalisation (ERR-09)
        else status = good | unknown
            V->>V: Assembler ocspResponses[]<br/>+ producedAt + certSerialNumber (normalize uppercase)
            V->>V: validationPolicy = GENERATION_TIME_SNAPSHOT
        end
    else OCSP indisponible (timeout ERR-05)
        V->>V: ocspResponses = []
        V->>V: validationPolicy = OCSP_UNAVAILABLE
    end
    V->>V: Assembler tsaCertificateChain[]<br/>+ eidasCertificateChain[]<br/>+ validationTimestamp (RFC3339 UTC ms)
    V-->>S: verificationMaterial complet (INV-282-04)

    S->>S: Inserer verificationMaterial<br/>dans ProofEnvelope
    S->>S: Exclure champ envelopeSeal (INV-282-02)
    S->>S: Canonicaliser JCS (RFC 8785)
    alt Echec canonicalisation
        S-->>S: REJET finalisation (ERR-02)
    end
    S->>S: Hash SHA3-384 du payload canonicalise

    S->>HSM: Sign CKM_ECDSA(hash, kid)<br/>algorithme = ECDSA-P384-SHA3-384
    alt Signature echoue
        HSM-->>S: Erreur (ERR-03)
    else Signature OK
        HSM-->>S: signature (raw ECDSA, base64url)
    end

    S->>S: Assembler envelopeSeal :<br/>algorithm + signature + kid<br/>+ signedAt + certificateChain[]
    S->>S: Valider formats contractuels<br/>(regex §5.1, INV-282-12)
    alt Format invalide
        S-->>S: REJET finalisation (ERR-06)
    end

    Note over S: Transition UNSEALED -> SEALED

    S->>DB: INSERT atomique<br/>(payload complet avec envelope_seal JSONB)
    Note over DB: Trigger PD-272 :<br/>tout UPDATE futur interdit

    Note over S: Etat SEALED (terminal, INV-282-09)

5bis.3 Flux de verification tierce (Mode A offline / Mode B online)¶

sequenceDiagram
    participant T as Verificateur tiers
    participant E as ProofEnvelope (document)
    participant TS as Trust-store local (H-01)
    participant BC as Blockchain publique<br/>(Mode B uniquement)

    T->>E: Extraire envelopeSeal + verificationMaterial
    T->>T: Verifier validationPolicy<br/>(GENERATION_TIME_SNAPSHOT | OCSP_UNAVAILABLE)

    T->>T: Extraire payload = enveloppe SANS envelopeSeal (INV-282-02)
    T->>T: Canonicaliser JCS (RFC 8785)
    T->>T: Hash SHA3-384 du payload canonicalise

    T->>T: crypto.verify(null, hash, publicKey, signature)<br/>(raw ECDSA — pas de createVerify)
    Note over T: INV-282-03 : toute modification<br/>d'un octet invalide la verification

    alt Signature invalide
        T-->>T: ECHEC verification (ERR-03)
    end

    T->>E: Extraire certificateChain[] (envelopeSeal)<br/>+ eidasCertificateChain[]
    T->>TS: Verifier chaine jusqu'a ancre de confiance
    alt Chaine non verifiable
        T-->>T: ECHEC verification (ERR-08)
    end

    T->>E: Extraire kid (envelopeSeal)
    T->>T: Identifier cle via kid + chaine embarquee<br/>(INV-282-11 : rotation de cle)

    alt validationPolicy = GENERATION_TIME_SNAPSHOT
        T->>E: Extraire ocspResponses[]
        T->>T: Verifier OCSP status pour chaque certificat
        T->>T: Confirmer producedAt <= validationTimestamp
    else validationPolicy = OCSP_UNAVAILABLE
        T->>T: Accepter sans OCSP<br/>(policy degradee documentee)
    end

    T->>E: Extraire tsaCertificateChain[]
    T->>T: Verifier token TSA (RFC 3161, PD-81)<br/>via chaine TSA embarquee

    opt Mode B uniquement
        T->>BC: Verifier ancrage blockchain<br/>(hors perimetre INV-282-04)
    end

    T->>T: Verification complete : VALIDE

6. Cas d'erreur¶

Note ERR-05 (garde-fou exploitation) : un mecanisme de monitoring doit alerter si le taux d'enveloppes generees avec OCSP_UNAVAILABLE depasse 10% sur une fenetre glissante de 1 heure. Ce mecanisme est hors perimetre fonctionnel de PD-282 mais DOIT etre implemente dans l'infrastructure de monitoring existante.

7. Criteres d'acceptation (testables)¶

8. Scenarios de test (Given / When / Then)¶

• T-01 Integrite nominale
• Given une enveloppe complete non scellee valide
• When le sceau est produit puis verifie

• Then la verification cryptographique reussit

• T-02 Alteration post-scellement

• Given une enveloppe scellee valide
• When un octet quelconque est modifie

• Then la verification echoue

• T-03 Materiel eIDAS complet

• Given une generation nominale avec OCSP disponible
• When l'enveloppe est finalisee

• Then verificationMaterial contient chaines + OCSP + timestamp + policy GENERATION_TIME_SNAPSHOT

• T-04 OCSP indisponible

• Given repondeur OCSP indisponible jusqu'au timeout contractuel
• When l'enveloppe est finalisee en mode degrade autorise

• Then ocspResponses=[] et validationPolicy=OCSP_UNAVAILABLE

• T-05 Immutabilite

• Given une enveloppe SEALED
• When une mutation est demandee

• Then la transition est refusee (SEALED -> * interdit)

• T-06 Rotation cle

• Given une enveloppe signee avec un kid historique
• When la cle courante a change
• Then la verification de l'enveloppe historique reste valide via chaine embarquee

9. Hypotheses explicites¶

10. Contraintes techniques (stack) et points a clarifier¶

10.1 Contraintes techniques confirmees (projet cible)¶

• Projet cible presume : ProbatioVault-backend.
• Stack contractuelle : NestJS + TypeORM + PostgreSQL.
• Formats d'artefacts : JSON (jsonb), certificats DER encodes base64, timestamps RFC3339 UTC.
• Toute mention de stack non conforme (ex. Spring Boot, Swift/SwiftUI) est interdite.

10.2 Points a clarifier¶

References¶

• Epic : Pas d'epic parent (story independante, labels: crypto, legal-compliance, rfc-pv-proof)
• JIRA : PD-282
• Repos concernes : ProbatioVault-backend
• Documents associes :
• RFC PV-PROOF-001 v1.1.0 (2026-03-01)
• PD-81 (LegalCompositeProof)
• PD-272 (immutability trigger)
• PD-280 (modele d'etats PENDING/INDETERMINATE)