Aller au contenu

PD-282 — Rapport de confrontation (Etape 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

  • Specification (Etape 1) : PD-282 — ProofEnvelope auto-verifiable : scellement HSM global et matériel eIDAS/OCSP embarqué
  • Tests (Etape 2) : PD-282 — Scénarios de tests contractuels
  • Review Phase 1 (Claude) : Les 16 ecarts identifies par Claude lors de la review

2. Convergences

  • Le triptyque fonctionnel central est aligné : envelopeSeal global, canonicalisation JCS hors envelopeSeal, et invalidation à la moindre altération (INV-282-01/02/03, CA-01/02/03, TC-NOM-01/02).
  • La structure attendue de verificationMaterial est convergente entre spec et tests (chaînes cert, OCSP, validationTimestamp, validationPolicy) (§5.1.2, CA-04/10, TC-NOM-03, TC-ERR-04).
  • Le comportement dégradé OCSP est explicitement repris dans les tests (ERR-05 ↔ TC-ERR-05) : autorisation uniquement avec validationPolicy=OCSP_UNAVAILABLE et ocspResponses=[].
  • L’immutabilité post-scellement et la terminalité de SEALED sont cohérentes entre spec et tests (INV-282-08/09/10, §5.4, TC-NOM-05/06, TC-ERR-07).
  • La vérification historique après rotation de clé est traitée de façon concordante (INV-282-11, CA-09, TC-NOM-07).
  • Le rejet explicite des violations de format/regex/longueur est cohérent (INV-282-12, ERR-06, TC-ERR-06, TC-NEG-01..07).
  • La non-régression vis-à-vis PD-272/PD-280 est présente dans les trois sources (objectif spec, tests TC-NR-01/02, review qui confirme l’enjeu d’alignement).
  • Les limites de testabilité externe (perf P95, juridique eIDAS, trust-store tiers) sont reconnues de manière cohérente (spec Q-02/H-04/H-01, tests §9 Règles non testables, review).

3. Divergences

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

  • DIV-01 (BLOQUANT) : Tests d’invariants référencés mais absents en scénarios définis.
  • Source A (Tests, matrice/§5) : référence TC-INV-06, TC-INV-07, TC-INV-09, TC-INV-10.
  • Source B (Tests, sections scénarios) : aucun scénario détaillé pour ces IDs.

  • Impact : traçabilité de couverture non vérifiable pour invariants non négociables.

  • DIV-02 (BLOQUANT) : Contradiction sur l’intégrité “tout octet”.

  • Source A (Specification, INV-282-03) : “Tout octet modifié ... DOIT rendre la vérification invalide.”
  • Source B (Tests, TC-NOM-02) : ajoute “hors normalisation transport” (notion non définie contractuellement).

  • Impact : ambiguïté de périmètre d’intégrité, risque d’interprétations divergentes du verdict crypto.

  • DIV-03 (MAJEUR) : Politique OCSP à la fois contractualisée et laissée ouverte.

  • Source A (Specification, ERR-05) : comportement dégradé explicitement autorisé.
  • Source B (Specification, Q-03) : décision “bloquant obligatoire vs mode dégradé autorisé” encore ouverte.

  • Impact : contradiction interne de contrat, décision de finalisation non stabilisée.

  • DIV-04 (MAJEUR) : Exigence de réussite Mode A vs prérequis externe non garanti.

  • Source A (Specification, CA-08) : réussite Mode A exigée.
  • Source B (Specification, H-01) : échec possible si racine de confiance absente côté vérificateur.

  • Impact : critère d’acceptation potentiellement inatteignable selon contexte tiers.

  • DIV-05 (MAJEUR) : Exigences d’audit dans les tests non spécifiées dans le contrat.

  • Source A (Tests, TC-NOM-01/02, §8) : logs d’audit et journalisation de motifs exigés.
  • Source B (Specification) : aucun contrat explicite de journal d’audit/corrélation événementielle.

  • Impact : divergence “contrat produit” vs “contrat test”, risque de faux KO/OK.

  • DIV-06 (MAJEUR) : Codes d’erreur API requis par tests mais non définis.

  • Source A (Tests, §8, TC-NR-04) : stabilité de codes/erreurs contractuels exigée.
  • Source B (Specification, Q-06) : mapping erreurs API explicitement non tranché.

  • Impact : non-testabilité déterministe des rejets côté API.

  • DIV-07 (MAJEUR) : Critères P95 contractualisés sans environnement de référence fixé.

  • Source A (Specification, §5.2) : bornes chiffrées P95.
  • Source B (Specification Q-02 + Tests §9) : environnement manquant, testabilité partielle.

  • Impact : conformité perf contestable/non objectivable.

  • DIV-08 (MAJEUR) : Sémantique root CA non stabilisée pour la vérification offline.

  • Source A (Specification, Q-05) : inclusion root CA “obligatoire ou optionnelle” non décidée.
  • Source B (Tests, TC-NOM-04, TC-ERR-08) : vérification de chaîne attendue en Mode A.

  • Impact : résultat Mode A dépendant d’une convention non contractée.

  • DIV-09 (MAJEUR) : Alignement PD-280 déclaré compatible mais non verrouillé.

  • Source A (Specification, objectifs + H-02/Q-04) : compatibilité supposée à confirmer.
  • Source B (Tests, TC-NR-02) : non-régression PD-280 attendue comme acquise.

  • Impact : risque de conflit inter-story sur machine à états au moment d’intégration.

  • DIV-10 (MAJEUR) : Politique sécurité sur secrets en entrée ambiguë.

  • Source A (Specification, INV-282-06) : aucun secret en clair autorisé dans enveloppe.
  • Source B (Tests, TC-NEG-08) : résultat “rejet / nettoyage” (deux comportements possibles).

  • Impact : comportement sécurité non déterministe, audit/compliance fragile.

  • DIV-11 (MAJEUR) : tsaCertificateChain imposée sans artefact TSA associé explicitement défini.

  • Source A (Specification, verificationMaterial.tsaCertificateChain) : chaîne TSA requise.
  • Source B (Specification/tests) : pas d’objet de preuve TSA explicite (token/référence) dans le modèle testé.

  • Impact : complétude probatoire TSA ambiguë, vérifiabilité sémantique partielle.

  • DIV-12 (MAJEUR) : Invariant “détection de secrets” partiellement testable vs exigence absolue.

  • Source A (Specification, INV-282-06) : interdiction absolue.
  • Source B (Tests, §9) : limites d’exhaustivité (contrôles techniques non totaux).
  • Impact : écart entre exigence normative et capacité de preuve de conformité.

4. Zones d'ombre

  • Référence épique non stabilisée (Référence épique non fournie vs EPIC-XX placeholder) : rattachement gouvernance incomplet.
  • Définition opérationnelle de “résolution manuelle uniquement” pour l’état SEALED absente (processus, acteur, traçabilité).
  • Moment exact de normalisation certSerialNumber (acceptation case-insensitive puis uppercase) non précisé dans le flux.
  • Contrat inter-story PD-280 non matérialisé (source canonique des états globaux non incluse dans les entrées).
  • Politique de fréquence/encadrement du mode OCSP_UNAVAILABLE non documentée (seuil, alerte, gouvernance).
  • Frontière exacte entre “preuve temporelle” et exigences de recevabilité légale eIDAS non formalisée techniquement.
  • Dépendances trust-store vérificateur tiers non spécifiées (profil minimal attendu, compatibilité environnement air-gapped).
  • Portée exacte “Mode B online public” (sources autorisées, exigences réseau minimales) peu détaillée.

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