PD-282 — Rapport de confrontation (Gate 8 — Acceptabilite)¶

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

1. Sources confrontees¶

2. Convergences¶

2.1 Architecture INSERT-only et immutabilite¶

Les 4 documents convergent sur le pattern d'insertion atomique : - Spec §5.4 : UNSEALED transitoire en memoire, INSERT direct en SEALED, pas de sequence INSERT+UPDATE. - Tests TC-NOM-06 : verifie l'absence d'ecriture DB en etat UNSEALED et l'INSERT atomique SEALED. - Plan DA-02 : confirme "pas de colonne seal_status", INSERT toujours atomique. - Acceptabilite §5.1 : INV-282-08/09/10 traces comme couverts (TC-NOM-05, TC-ERR-07, TC-INV-09, TC-INV-10 passants).

Pas de divergence. Compatibilite PD-272 confirmee.

2.2 Algorithme de scellement¶

Les 4 documents convergent sur ECDSA-P384-SHA3-384 : - Spec §5.1.1 : regex ^ECDSA-P384-SHA3-384$, valeur fixe. - Tests TC-NOM-01 : verifie la conformite algorithmique. - Plan DA-03 : pre-hash SHA3-384 en software + CKM_ECDSA raw dans HSM. - Acceptabilite : confirme l'identifiant algorithme correct dans le code.

Convergence sur l'identifiant. Divergence d'implementation detectee (cf. DIV-01).

2.3 Canonicalisation JCS RFC 8785¶

Convergence complete : - Spec INV-282-02 : exclusion stricte de envelopeSeal avant canonicalisation. - Tests TC-NOM-01, TC-ERR-02 : couverture nominale et echec JCS. - Plan §4.2 : pipeline etape 3-4 (exclure envelopeSeal, canonicaliser JCS). - Acceptabilite : TC-NOM-01 passant, TC-ERR-02 passant.

2.4 Detection de secrets (INV-282-06)¶

Convergence complete : - Spec INV-282-06 : liste de patterns interdits (privateKey, secretKey, sessionToken, hmacSecret, dek). - Tests TC-INV-06, TC-NEG-08 : couverture nominale et adversariale. - Plan §4.2 : SecretDetectionService dedie. - Acceptabilite : tests passants, aucun ecart identifie.

2.5 Validation de format (INV-282-12)¶

Convergence complete : - Spec §5.1.⅕.1.2 : regex, longueurs, casse contractualisees. - Tests TC-ERR-06, TC-NEG-01..07 : couverture exhaustive des rejets format. - Plan §4.2 : EnvelopeFormatValidatorService dedie. - Acceptabilite : tests passants.

2.6 Rotation de cles (INV-282-11)¶

Convergence complete : - Spec INV-282-11, CA-09 : verification historique via kid + chaine embarquee. - Tests TC-NOM-07 : scenario kid K1 apres rotation vers K2. - Plan §4.4 : kid + certificateChain embarquee dans OfflineVerificationService. - Acceptabilite : TC-NOM-07 passant.

2.7 Machine d'etats SEALED terminal¶

Convergence complete : - Spec INV-282-09/10, §5.4 : SEALED -> * interdit. - Tests TC-NOM-06, TC-INV-09, TC-INV-10 : couverture exhaustive. - Plan DA-02 : coherent avec trigger PD-272. - Acceptabilite : tests passants.

2.8 Migration DDL¶

Convergence complete : - Spec §5.6 : ALTER TABLE legal_composite_proof ADD COLUMN envelope_seal JSONB NULL. - Plan §4.1 : migration PD282-AddEnvelopeSealColumn.ts dans agent-entity. - Acceptabilite : aucun ecart signale sur la migration.

2.9 Policy degradee OCSP_UNAVAILABLE¶

Convergence de principe : - Spec ERR-05 : timeout OCSP → validationPolicy=OCSP_UNAVAILABLE + ocspResponses=[]. - Tests TC-ERR-05 : scenario OCSP indisponible, finalisation autorisee si policy OCSP_UNAVAILABLE. - Plan §4.3 step 3 : "Si timeout total → policy OCSP_UNAVAILABLE, ocspResponses=[]." - Acceptabilite : mecanisme present mais divergence d'implementation detectee (cf. DIV-04).

2.10 Rejet OCSP status=revoked¶

Convergence : - Spec ERR-09 : "OCSP status=revoked detecte → Rejet finalisation (certificat revoque)." - Plan (Reserve ECT-02) : "rejette la finalisation si status=revoked detecte (exception OCSP_CERT_REVOKED)." - Tests : couvert implicitement par TC-ERR-05 et la logique de rejet. - Acceptabilite : non contredit.

2.11 Dependances confirmees¶

Toutes les dependances externes sont confirmees disponibles : - PD-272 (immutabilite trigger) : Spec §5.6, Plan §6, Acceptabilite §5.1 — pas de conflit. - PD-81 (LegalCompositeProof, token TSA) : Spec §3, Plan §6 — disponible. - PD-280 (modele d'etats) : Spec §2 — disponible (reserve ZO-02 pour etats futurs). - PD-37 (JsonCanonicalizeService) : Plan §6 — disponible.

3. Divergences¶

Les conflits ne doivent JAMAIS etre lisses. Chaque divergence est rendue visible.

DIV-01 — Double-hash dans le pipeline crypto sign/verify¶

• Plan DA-03 : "Pre-hash SHA3-384 en software (js-sha3) puis signature ECDSA P-384 raw dans le HSM." Le plan specifie CKM_ECDSA (raw) et mentionne "peut necessiter ajout ECDSA_RAW dans SignatureAlgorithm enum." Verification cote Node.js via crypto.createVerify('SHA3-384') avec dsaEncoding: 'ieee-p1363' (§4.4 etape 6).
• Acceptabilite E-01 (BLOQUANT) : L'implementation utilise SignatureAlgorithm.ECDSA_SHA384 (qui re-hash en SHA-384, pas SHA3-384) au lieu de ECDSA_RAW. Cote verification, createVerify('SHA3-384') re-hash le buffer deja hashe en SHA3-384. Pipeline sign : data → SHA3-384 → [SHA-384 dans HSM] → signature. Pipeline verify : data → SHA3-384 → [SHA3-384 dans createVerify] → compare. Les deux chaines de hachage sont differentes.
• Spec INV-282-01, INV-282-03 : exigent que le sceau soit valide cryptographiquement et que toute modification d'un octet invalide la verification.
• Impact : L'integrite cryptographique est compromise. Les 259 tests passent car le HSM est mocke — le mock ne reproduit pas le double-hashing. En production, sign et verify produiraient des resultats incoherents. INV-282-01, INV-282-03, CA-01, CA-02 ne sont pas satisfaits en conditions reelles.
• Gravite : BLOQUANT

DIV-02 — Structure envelope_seal imbriquee en base¶

• Spec §5.1 : definit envelopeSeal (§5.1.1) et verificationMaterial (§5.1.2) comme structures distinctes au sein de la ProofEnvelope.
• Plan DA-01 : colonne envelope_seal JSONB sur legal_composite_proof. Le plan ne precise pas explicitement si le contenu est EnvelopeSeal ou SealedProofEnvelope.
• Acceptabilite E-02 (BLOQUANT) : L'implementation persiste le wrapper SealedProofEnvelope = {envelopeSeal, verificationMaterial} dans la colonne envelope_seal, pas EnvelopeSeal directement. Le verificateur offline-verification.service.ts:47 lit envelope.envelopeSeal et le cast en EnvelopeSeal. Apres reconstruction depuis la DB, le cast echoue car la structure est imbriquee.
• Impact : Echec de verification apres reconstruction depuis DB. INV-282-01, INV-282-04 compromis. Mode A et Mode B inutilisables pour toute enveloppe reconstruite.
• Gravite : BLOQUANT

DIV-03 — Bypass de l'ancre de confiance (trust anchor optionnel)¶

• Spec H-01 : "La racine de confiance necessaire a la validation cert est disponible cote verificateur." CA-08 : "sous reserve que le trust-store du verificateur contienne la racine de confiance."
• Plan §4.4 : verification de la chaine de certificats (etape 7) sans mention explicite du caractere obligatoire de trustedRoots.
• Acceptabilite S-01 (BLOQUANT) : OfflineVerificationService.verify() accepte trustedRoots optionnel. Sans trusted roots, verifyCertificateChain() verifie uniquement la coherence interne de la chaine. Un attaquant peut generer sa propre paire EC P-384, signer un faux payload, injecter son cert dans certificateChain, et obtenir valid=true.
• Spec : documente H-01 comme hypothese mais ne prescrit pas le comportement en l'absence de trust-store. L'implementation aurait du echouer explicitement (pattern fail-safe).
• Impact : Mode A contournable par un certificat auto-signe. INV-282-04 (auto-verifiabilite tierce) invalide si aucune ancre de confiance n'est exigee.
• Gravite : BLOQUANT

DIV-04 — Policy OCSP incoherente¶

• Spec ERR-05 : ocspResponses=[] autorise uniquement avec validationPolicy=OCSP_UNAVAILABLE. Reciproquement, GENERATION_TIME_SNAPSHOT implique des reponses OCSP presentes.
• Tests TC-NOM-03 : verifie validationPolicy=GENERATION_TIME_SNAPSHOT avec OCSP disponible — coherent avec la spec.
• Plan §4.3 step 3 : "Si timeout total → policy OCSP_UNAVAILABLE, ocspResponses=[]" — coherent.
• Acceptabilite E-03 (MAJEUR) : VerificationMaterialAssembler peut produire validationPolicy=GENERATION_TIME_SNAPSHOT avec ocspResponses=[] quand aucune requete OCSP n'est soumise (legal-composite-proof.service.ts:109 passe [] comme OCSP requests).
• Impact : Violation INV-282-05. L'enveloppe porte une policy affirmant un snapshot OCSP inexistant. Interpretation probatoire ambigue.
• Gravite : MAJEUR

DIV-05 — Mode B non implemente¶

• Spec §2 Inclus : "Verification tierce en mode online public (sans service ProbatioVault)."
• Tests TC-NOM-09 : scenario nominal Mode B defini (verification OCSP en ligne confirme non-revocation).
• Plan §4.4 : "Mode B uniquement : verification OCSP en ligne constitutive (echec → valid=false)." Le plan insiste : Mode B DOIT requeter les serveurs OCSP/CRL publics.
• Acceptabilite S-02 (MAJEUR) : verifyOnlineOcsp() verifie uniquement la periode de validite du certificat (dates), sans requeter les responders OCSP/CRL publics.
• Acceptabilite T-01 (MAJEUR) : TC-NOM-09 (Mode B nominal) absent de l'implementation des tests.
• Impact : Mode B tel que specifie et planifie n'est pas fonctionnel. Un certificat revoque passe la verification online.
• Gravite : MAJEUR

DIV-06 — Triple duplication de verificationMaterial¶

• Spec §5.1.2 : definit une structure unique verificationMaterial.
• Plan §4.2/4.3 : VerificationMaterialAssembler produit un verificationMaterial unique, integre dans generateProof().
• Acceptabilite E-05 (MAJEUR) : Trois versions coexistent dans le code :
• envelopePayload.verificationMaterial (ligne 121) — enhanced version dans le payload signe
• sealedEnvelope.verificationMaterial (ligne 129) — dans le wrapper scelle
• colonne verification_material legacy (ligne 142) — ancien format
• Impact : Source de verite ambigue. Risque de desynchronisation entre les trois copies. Un verificateur tiers ne sait pas quelle version fait autorite.
• Gravite : MAJEUR

DIV-07 — Risque SSRF sur les URLs OCSP¶

• Spec : ne mentionne pas de protection SSRF pour les URLs OCSP.
• Plan DA-05 : definit @peculiar/asn1-ocsp pour l'encodage OCSP mais ne mentionne pas de allowlist/denylist.
• Acceptabilite S-03 (MAJEUR) : OcspClientService effectue fetch() sur des URLs extraites des extensions AIA des certificats sans allowlist, denylist ni controle de schema/reseau.
• Impact : Un certificat forge avec une URL AIA malveillante (ex: http://169.254.169.254/...) pourrait scanner le reseau interne ou exfiltrer des donnees. Defense-in-depth non couverte par la spec ni le plan.
• Gravite : MAJEUR

DIV-08 — Parsing OCSP heuristique vs librairie ASN.1¶

• Plan DA-05 : "Utiliser @peculiar/asn1-ocsp pour l'encodage/decodage ASN.1 OCSP." Decision architecturale explicite.
• Acceptabilite S-04 (MINEUR) : L'implementation decode l'ASN.1 par inspection d'octets au lieu d'utiliser @peculiar/asn1-ocsp.
• Impact : Non-conformite avec la decision architecturale DA-05. Risque de reponse OCSP forgee influencant le statut. A corriger lors de l'integration OCSP reelle.
• Gravite : MINEUR

DIV-09 — Test de compatibilite PD-280 absent¶

• Tests §6 : TC-NR-02 defini — "Compatibilite PD-280 modele d'etats — Transitions autorisees/interdites inchangees."
• Acceptabilite §5.2 : TC-NR-02 marque comme absent dans l'implementation.
• Impact : Pas de verification automatisee de non-regression sur le modele d'etats PD-280. Risque de conflit silencieux si PD-280 evolue.
• Gravite : MAJEUR

4. Zones d'ombre¶

ZO-01 — Environnement de reference performance (Q-02)¶

Non resolu depuis la specification. Les bornes P95 (latence scellement 500ms, timeout OCSP 2000ms, overhead 17KB) ne sont pas verifiables sans definition de l'hote cible. Identifie dans les 3 documents (Spec Q-02, Tests §9 "Regles non testables", Plan §8 risques).

ZO-02 — Alignement jeu d'etats PD-280 (Q-04)¶

Point a clarifier dans la Spec (Q-04). Le Plan presuppose la compatibilite (H-02). L'Acceptabilite note l'absence de TC-NR-02. Si PD-280 introduit des etats incompatibles avec SEALED terminal, une revision de la machine d'etats sera requise.

ZO-03 — Inclusion root CA dans les chaines (Q-05)¶

Spec Q-05 : "obligatoire ou optionnelle selon politique trust-store cible." Plan DA-06 definit les intermediaires via ConfigService mais ne tranche pas sur l'inclusion du root. L'Acceptabilite S-01 revele que l'absence de trust roots rend la verification permissive. La decision Q-05 conditionne la strategie de correctif de DIV-03.

ZO-04 — Couverture ocsp-client.service.ts (9.83%)¶

L'Acceptabilite note 9.83% de couverture. Les Tests contractuels definissent TC-ERR-05 (OCSP timeout) mais pas de scenarios exhaustifs pour le client OCSP (erreurs reseau, reponses malformees, timeouts partiels). Le Plan §4.3 decrit le pipeline d'assemblage sans detailler les scenarios d'erreur du client.

ZO-05 — Couverture offline-verification.service.ts (43.43%)¶

L'Acceptabilite note 43.43% de couverture. Les branches Mode B et verification de chaine de certificats ne sont pas couvertes. Coherent avec DIV-05 (Mode B non implemente).

ZO-06 — Interoperabilite sign(HSM)/verify(Node.js) en CI¶

Le Plan §8 identifie le risque "Interop SHA3-384 sign(HSM) / verify(Node.js)" avec mitigation "test d'interoperabilite explicite DOIT etre execute en CI (TC-INV-xx-INTEROP)." Ce test n'est mentionne ni dans les Tests contractuels ni dans l'Acceptabilite. DIV-01 confirme que cette interop n'est pas validee.

ZO-07 — Compatibilite ESM/CJS des packages @peculiar/*¶

Le Plan DA-05 identifie le risque ESM/CJS et propose un fallback dynamic import. L'Acceptabilite S-04 revele que @peculiar/asn1-ocsp n'est pas utilise (parsing heuristique). La compatibilite ESM/CJS n'a donc pas ete testee.

ZO-08 — Sonar QG ERROR sur module TSA (PD-281)¶

L'Acceptabilite note un Sonar QG ERROR (5 violations MINOR/MAJOR dans le module TSA — PD-281), avec 0 violation dans le code PD-282 (legal-pre). Le QG global est en erreur. Decision a prendre : le QG ERROR d'un module adjacent bloque-t-il la Gate 8 de PD-282 ?

ZO-09 — Monitoring OCSP_UNAVAILABLE >10%¶

La Spec note (ERR-05) qu'un mecanisme de monitoring est "hors perimetre fonctionnel PD-282 mais DOIT etre implemente dans l'infrastructure de monitoring existante." Aucun document ne precise quand ni par quelle story ce monitoring sera implemente.

ZO-10 — ECDSA_RAW dans l'enum SignatureAlgorithm¶

Le Plan DA-03 note "peut necessiter ajout ECDSA_RAW dans SignatureAlgorithm enum." L'Acceptabilite E-01 montre que cet ajout n'a pas ete fait (utilisation de ECDSA_SHA384 a la place). La zone d'ombre est de savoir si l'enum existante couvre le cas raw ou si un ajout est requis.

5. Synthese des ecarts par gravite¶

6. Recommandation¶

• Proceder — convergence confirmee, aucun conflit bloquant
• Rework necessaire — divergences a resoudre avant de continuer
• Escalade — decision humaine requise sur un point structurant

Justification : 3 ecarts BLOQUANTS compromettent le coeur cryptographique de PD-282 (pipeline sign/verify DIV-01, structure DB DIV-02, ancre de confiance DIV-03). Les 5 ecarts MAJEURS affectent la conformite fonctionnelle (Mode B DIV-05, policy OCSP DIV-04, SSRF DIV-07, duplication DIV-06, non-regression PD-280 DIV-09). Les convergences sont solides (architecture INSERT-only, modele de donnees, detection secrets, validation format, rotation cles, migration DDL), mais l'implementation crypto diverge du plan et de la spec sur des points fondamentaux pour la force probante de l'enveloppe.

Priorite de correction : 1. DIV-01 (double-hash) — sans correction, aucune signature n'est verifiable en production 2. DIV-02 (structure imbriquee) — sans correction, la reconstruction depuis DB echoue 3. DIV-03 (trust anchor) — sans correction, Mode A est contournable par un certificat auto-signe 4. DIV-04 + DIV-05 (OCSP policy + Mode B) — coherence spec/implementation 5. DIV-06 + DIV-07 (duplication + SSRF) — maintenabilite et defense-in-depth 6. DIV-09 (TC-NR-02) — non-regression PD-280