PD-282 — Rapport de confrontation (Étape 5)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate 5 PMO. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

2. Convergences¶

C-01 — Algorithme cryptographique. Les quatre documents techniques convergent sur ECDSA-P384-SHA3-384 : spec §5.1.1 (algorithm valeur fixe), tests TC-NOM-01, plan DA-03 (pre-hash SHA3-384 + raw ECDSA HSM), code contract envelope-seal-pipeline (invariant algorithme fixe).

C-02 — Canonicalisation JCS et exclusion envelopeSeal. Spec INV-282-02, tests TC-NOM-01/TC-ERR-02, plan §4.2 pipeline étape 3-4, code contract envelope-seal-pipeline invariant INV-282-02 : tous exigent l'exclusion stricte du champ envelopeSeal avant canonicalisation RFC 8785.

C-03 — 12 invariants non négociables. La matrice de couverture des tests (§2) couvre les 12 invariants INV-282-01 à INV-282-12. Le plan §5 mappe chaque invariant à un ou plusieurs modules. Les code contracts reprennent chaque invariant dans le module propriétaire.

C-04 — État SEALED terminal. Spec §5.4 (SEALED -> * : INTERDITE), tests TC-NOM-06/TC-INV-09/TC-INV-10, plan DA-02 (pas de colonne seal_status, INSERT direct en SEALED), code contract proof-envelope-entity (INV-282-09, INV-282-10) : convergence complète.

C-05 — Immutabilité via trigger PD-272. Spec INV-282-08, tests TC-NOM-05/TC-ERR-07, plan DA-02/DA-04 (INSERT atomique, pas d'UPDATE), code contract proof-envelope-entity (interdit de modifier le trigger) : convergence sur le mécanisme de protection.

C-06 — Structure envelopeSeal et verificationMaterial. Les formats contractuels (regex, tailles, encodages) de la spec §5.1 sont repris fidèlement dans le code contract format-validation et testés par TC-NEG-01 à TC-NEG-10.

C-07 — Policy OCSP dégradée. Spec ERR-05/§5.1.2, tests TC-ERR-05/TC-NOM-04, plan §4.3 pipeline étape 3, code contract verification-material-assembly : si timeout total OCSP → validationPolicy=OCSP_UNAVAILABLE et ocspResponses=[].

C-08 — Rotation de clé et vérification historique. Spec INV-282-11/CA-09, tests TC-NOM-07, plan §4.4 pipeline étape 5-6, code contract offline-verification : vérification via kid + certificateChain embarquée, sans dépendance à la clé courante.

C-09 — Détection de secrets. Spec INV-282-06 (5 patterns interdits), tests TC-INV-06/TC-NEG-08, plan §4.2 pipeline étape 2, code contract secret-detection : convergence sur liste, moment d'exécution (avant scellement) et comportement (rejet strict).

C-10 — Dépendances externes. Plan §6 identifie PD-272, PD-81, PD-280, PD-37 comme disponibles. La spec §7 les référence. Les code contracts utilisent JsonCanonicalizeService (PD-37) explicitement. Aucune contradiction sur l'état des dépendances.

3. Divergences¶

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

DIV-01 — Rejet status=revoked : règle métier ajoutée hors spécification [MAJEUR]

• Spec (§6 ERR-05, §5.1.2) : seul le cas d'indisponibilité/timeout OCSP est contractualisé. Le statut revoked fait partie de l'enum autorisée (good|revoked|unknown) mais aucun comportement de rejet n'est spécifié pour status=revoked.
• Plan (§3 Reserve ECT-02, §4.3 étape 4) : « Le VerificationMaterialAssembler rejette la finalisation si status=revoked détecté (exception OCSP_CERT_REVOKED) ».
• Code Contract (verification-material-assembly) : « Si un OCSP response a status=revoked: rejet finalisation (certificat revoqué) ».
• Review : confirme l'écart (constatation ligne 1).
• Impact : introduction d'une règle métier non contractualisée. Si acceptée, la spec doit être amendée. Si refusée, le plan doit retirer ce comportement.

DIV-02 — INV-282-07 redéfini plutôt qu'implémenté [BLOQUANT]

• Spec (§4 INV-282-07) : « tout artefact crypto temporaire (clé/fragment/DEK/ReKey) est chiffré au repos (AES-256-GCM ou envelope HSM) ».
• Plan (§5, ligne INV-282-07) : « Hash non réversible, clé dans HSM ».
• Code Contract (envelope-seal-pipeline) : « Aucun artefact crypto temporaire en clair (hash et signature sont non-réversibles, clé privée reste dans HSM) ».
• Review : confirme l'écart (constatation ligne 2, BLOQUANT).
• Impact : le plan substitue une justification d'absence de secret exposé (« hash non réversible ») à l'exigence contractuelle de chiffrement au repos. L'invariant constitutionnel n'est pas démontré sur son périmètre réel (DB/blobs/fichiers temporaires applicatifs).

DIV-03 — TC-INV-07 non réalisable dans le plan [BLOQUANT]

• Tests (TC-INV-07) : « Chaque artefact est chiffré au repos (AES-256-GCM ou envelope HSM). Aucune persistance en clair n'est détectée ».
• Plan (§7) : aucun mécanisme d'observabilité, d'audit de stockage ou de simulation de persistance décrit pour exécuter ce test.
• Review : confirme (constatation ligne 3, BLOQUANT).
• Impact : test d'invariant constitutionnel non exécutable. Le plan doit décrire le dispositif technique permettant de vérifier le chiffrement au repos.

DIV-04 — TC-NOM-08 (crash pre/post-commit) non outillé [BLOQUANT]

• Tests (TC-NOM-08) : « Crash simulé avant commit puis après commit (deux exécutions distinctes) ».
• Spec (§5.5) : exige rollback total pre-commit et réconciliation post-commit.
• Plan (§7) : ne définit ni mécanisme de simulation de crash (injection de faute), ni points d'observation pour valider l'atomicité.
• Review : confirme (constatation ligne 4, BLOQUANT).
• Impact : validation de l'atomicité multi-composant non objectivable. Le plan doit expliciter comment simuler un crash transactionnel et observer l'état résultant.

DIV-05 — Mode B affaibli par « vérification en ligne optionnelle » [MAJEUR]

• Spec (§3) : « Mode B : vérification online publique (blockchain/OCSP/CRL publics), sans dépendance ProbatioVault ».
• Code Contract (offline-verification) : « Mode B: utilise les données embarquées + vérification en ligne optionnelle (OCSP/CRL publics) ».
• Plan (§4.4 pipeline étape 8) : « Mode B uniquement : vérification OCSP en ligne optionnelle ».
• Review : confirme (constatation ligne 5, MAJEUR).
• Impact : le mot « optionnelle » rend le Mode B identique au Mode A avec une option supplémentaire, alors que la spec le définit comme un mode de vérification online publique. Le contrat de OfflineVerificationService doit clarifier si la vérification en ligne est constitutive ou optionnelle en Mode B.

DIV-06 — Code contracts contiennent des invariants hors spec [MAJEUR]

• Spec (§4) : 12 invariants INV-282-01 à INV-282-12.
• Code Contracts : ajoutent des invariants d'implémentation (ex. envelope-seal-pipeline : « kid = label de la clé HSM courante », « Utiliser exclusivement JsonCanonicalizeService (PD-37) », « Encodage signature: base64url RFC 4648 sans padding » ; hash-extension : « hashSha3_384() retourne un hash hex lowercase de 96 caractères »).
• Review : confirme (constatation ligne 7, MAJEUR).
• Impact : mélange entre exigences normatives (auditables contre la spec) et choix techniques (auditables contre le plan). Risque d'ambiguïté d'audit en Gate 8. Les invariants de code contracts devraient distinguer clairement les deux niveaux.

DIV-07 — Framework de test non spécifié [MAJEUR]

• Tests (§1-§10) : scénarios détaillés mais sans mention du framework d'exécution.
• Plan (§7) : tableau par niveau (unitaire, intégration, négatif) sans préciser Jest, Vitest, ou autre.
• Review : confirme (constatation ligne 9, MAJEUR).
• Impact : ambiguïté d'exécution des suites contractuelles. Le projet ProbatioVault-backend utilise vraisemblablement Jest (stack NestJS), mais ce n'est pas contractualisé.

DIV-08 — Compatibilité ESM/CJS des nouvelles dépendances non documentée [MAJEUR]

• Plan (§6) : introduit @peculiar/asn1-ocsp et @peculiar/asn1-x509 comme nouvelles dépendances.
• Code Contract (ocsp-client) : confirme l'utilisation.
• Review : signale le risque de compatibilité ESM/CJS (constatation ligne 10, MAJEUR).
• Impact : les packages @peculiar/* sont ESM-first. Si le backend est en CJS, un risque de rupture au runtime ou dans les tests existe. Le plan doit documenter la compatibilité.

DIV-09 — signedAt exclu du sceau : décision implicite non contractualisée dans la spec [MINEUR]

• Spec (§2 « Couverture de signature sur l'enveloppe complète hors champ envelopeSeal ») : signedAt est dans envelopeSeal, donc exclu par définition.
• Plan (§3 Reserve DIV-01) : documente cette conséquence et la qualifie d'acceptable avec mitigation (validationTimestamp + TSA PD-81).
• Impact : conséquence logique de l'architecture, mais la spec ne mentionne pas explicitement que signedAt n'est pas protégé par le sceau. Un attaquant pourrait modifier signedAt sans invalider la vérification. Le plan le documente ; la spec reste silencieuse.

4. Zones d'ombre¶

ZO-01 — Comportement sur ocspResponses[].status=unknown. La spec §5.1.2 autorise good|revoked|unknown dans l'enum. Le plan et les code contracts définissent un comportement pour good (accepté) et revoked (rejet selon DIV-01). Aucun document ne spécifie le comportement quand status=unknown. La finalisation est-elle autorisée ? Avec quelle policy ?

ZO-02 — Environnement de référence pour P95. Spec §5.2 et §10.2 Q-02 identifient le point comme ouvert. Le plan ne le résout pas. Tests §9 le classent comme « non testable ». La borne P95 latence scellement (500ms défaut, max 5000ms) et overhead (17KB défaut, max 64KB) restent non objectivables.

ZO-03 — Alignement PD-280 modèle d'états. Spec §10.2 Q-04 (« Jeu exact d'états métier final PD-280 — confirmer alignement UNSEALED/SEALED avec états globaux »). Le plan §6 indique PD-280 comme « Disponible » mais ne documente pas la vérification d'alignement. Tests TC-NR-02 couvre la non-régression mais pas la résolution de Q-04.

ZO-04 — Root CA dans les chaînes de certificats. Spec §10.2 Q-05 (« Inclusion root CA — obligatoire ou optionnelle ? »). Plan DA-06 configure les intermédiaires via ConfigService mais ne tranche pas la question. Impact direct sur Mode A (H-01 : trust-store du vérificateur).

ZO-05 — Mécanisme de réconciliation post-crash. Spec §5.5 réfère à un « mécanisme de réconciliation existant ». Plan §3 notes (AMB-04) : « le reconciliation handler existant dans le module legal-pre couvre le rattrapage ». Ni la spec ni le plan ne documentent comment ce mécanisme existant s'applique spécifiquement aux enveloppes PD-282.

ZO-06 — Monitoring seuil 10% OCSP_UNAVAILABLE. Spec §6 note ERR-05 exige un monitoring si le taux dépasse 10% sur 1h, qualifié « hors périmètre fonctionnel PD-282 mais DOIT être implémenté ». Aucun document ne décrit le propriétaire, le mécanisme, ni la story de destination de cette exigence. Aucun stub tracé.

ZO-07 — Variables CI pour tests d'intégration. Review constatation ligne 11 (MINEUR). Le plan ne documente pas les variables d'environnement CI nécessaires (DATABASE_URL, profil HSM test, etc.). Impact sur la reproductibilité en pipeline.

ZO-08 — OCSP du certificat HSM ProbatioVault lui-même. Plan §3 notes (RSC-01) : « le certificat HSM ProbatioVault n'a pas de responder OCSP public. À évaluer dans une story dédiée si nécessaire ». Aucune story de destination identifiée. L'auto-vérifiabilité complète de l'enveloppe dépend potentiellement de ce point.

5. Recommandation¶

• Procéder — convergence confirmée, aucun conflit bloquant
• Rework nécessaire — divergences à résoudre avant de continuer
• Escalade — décision humaine requise sur un point structurant

Justification : 3 divergences BLOQUANTES (DIV-02, DIV-03, DIV-04) portent sur des invariants constitutionnels non démontrables et des scénarios de test non outillés. Ces points doivent être résolus dans le plan avant soumission à Gate 5.

Actions minimales avant Gate 5 :