PD-282 — Rapport de confrontation (Étape 3)¶
Ce rapport est produit par l'orchestrateur Claude avant chaque gate PMO.
Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.
1. Sources confrontées¶
- Spécification (Étape 1) :
PD-282 - ProofEnvelope auto-verifiable...(sections 2 à 10, invariants INV-282-01..12, ERR-01..08, CA-01..12) - Tests contractuels (Étape 2) :
PD-282 - Scenarios de tests contractuels(matrice, TC-NOM/ERR/INV/NEG/NR, verdict QA) - Résultats Phase 1 — Review v3 (pré-gate) : synthèse des écarts ECR-01..ECR-10
2. Convergences¶
- Les deux documents convergent sur le socle crypto :
envelopeSealobligatoire, exclusion deenvelopeSealdu payload signé, invalidation sur mutation 1 octet (Spec INV-282-01/02/03, CA-01/02/03 ; Tests TC-NOM-01/02, TC-ERR-01/02/03). - Convergence explicite sur le contrat
verificationMaterialet la policy dégradée OCSP (OCSP_UNAVAILABLEavecocspResponses=[]) (Spec §5.1.2, ERR-05 ; Tests TC-NOM-03, TC-ERR-05, TC-NEG-06/07). - Convergence sur l’immutabilité et terminalité d’état (
SEALEDterminal,SEALED->UNSEALEDinterdit, pattern INSERT-only compatible PD-272) (Spec INV-282-08/09/10, §5.4/§5.6 ; Tests TC-NOM-05/06, TC-ERR-07, TC-INV-09/10, TC-NR-01). - Convergence sur la pérennité post-rotation de clé via
kid + certificateChain(Spec INV-282-11, CA-09 ; Tests TC-NOM-07, TC-NR-03). - Convergence sur la validation stricte format/regex/longueur/casse et rejet explicite (Spec INV-282-12, ERR-06 ; Tests TC-ERR-06, TC-NEG-01..07/10).
- Convergence sur les limites de testabilité déjà reconnues (perf P95 sans environnement de référence, trust-store tiers, recevabilité juridique) (Spec Q-02/Q-05, H-01/H-04 ; Tests §9 “Regles non testables”).
3. Divergences¶
⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.
- DIV-01 : Sortie attendue incohérente pour erreur crypto (ERR-03).
- Source A (Spécification §6, ERR-03) : « Signature invalide ou algorithme non conforme -> Rejet finalisation ».
- Source B (Tests TC-ERR-03) : « Rejet finalisation ou
valid=false». -
Impact : contrat de comportement ambigu côté API/service (erreur bloquante vs simple résultat de vérification), risque de non-déterminisme d’implémentation et de faux positifs en gate.
-
DIV-02 : Exigence produit Mode B présente, couverture nominale absente dans le plan de tests.
- Source A (Spécification §2 Inclus + §3 définitions) : Mode B (online public, sans dépendance ProbatioVault) est explicitement inclus.
- Source B (Tests) : pas de scénario nominal Mode B réussi ; seulement un scénario d’échec commun A/B (TC-ERR-08).
-
Impact : conformité fonctionnelle partielle non démontrée sur un périmètre déclaré “Inclus”.
-
DIV-03 : Invariant INV-282-07 annoncé comme couvert, mais stratégie de preuve partielle.
- Source A (Spécification INV-282-07) : exigence d’artefacts temporaires chiffrés au repos (AES-256-GCM ou envelope HSM).
- Source B (Tests matrice + TC-INV-07) : couverture marquée « Oui (partiel) », centrée sur absence de persistance en clair et audit statique.
-
Impact : démonstration incomplète de conformité à l’invariant constitutionnel crypto (preuve d’absence de persistance ≠ preuve exhaustive de chiffrement au repos dans tous chemins).
-
DIV-04 : Obligation de monitoring OCSP posée, non traduite en tests vérifiables.
- Source A (Spécification §6 note ERR-05) : alerte obligatoire si
OCSP_UNAVAILABLE> 10% sur 1h. - Source B (Tests) : aucun test dédié de ce comportement de monitoring (constat aussi repris en Review ECR-10).
- Impact : exigence opérationnelle obligatoire non objectivée avant gate (risque de conformité d’exploitation non prouvée).
4. Zones d'ombre¶
- Règle de décision non définie pour
ocspResponses[].status = revoked|unknown(acceptation/rejet/fallback non contractualisé explicitement dans Spec et non testé en nominal). - Politique exacte d’inclusion de la root CA dans les chaînes embarquées non tranchée (Q-05 ouvert ; dépendance trust-store tiers).
- Environnement de référence perf (Q-02) absent : impossible d’objectiver les bornes P95 (latence et overhead) malgré paramètres contractuels.
- Frontière exacte entre preuve technique et recevabilité juridique eIDAS (H-04) non fermée par un artefact de décision externe.
- Critères d’acceptation mesurables pour la heuristique anti-secrets (taux de faux positifs/faux négatifs, gouvernance d’évolution des patterns) non explicités.
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