Aller au contenu

PD-265 — 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 — “PD-265 — Monitoring TSA RFC 3161 et cycle de vie des clés opérationnelles” (Étape 1)
  • Tests — “PD-265 — Scénarios de tests contractuels” (Étape 2)

2. Convergences

  • Couverture explicite des invariants et critères : la matrice de couverture des tests mappe INV-265-01..12 vers CA-02..09 et des tests dédiés (Tests §2) en cohérence avec les invariants/CA de la spécification (Spec §4, §7).
  • Fail-closed NTS : bascule HEALTHY -> DEGRADED_NTS et blocage d’émission TST sur échec/offset NTS (Spec INV-265-01, Spec §6, Spec S1 ; Tests TC-NOM-01, TC-ERR-01).
  • Révocation OCSP/CRL : OCSP=REVOKED et CRL=LISTED/OCSP=UNKNOWN entraînent DEGRADED_REVOCATION (Spec INV-265-02, Spec §6, Spec S2 ; Tests TC-ERR-02, TC-ERR-03).
  • Labels HSM + CI : conventions pv-tsa-signing-YYYY et échec pipeline si non conforme (Spec INV-265-03, INV-265-04, Spec §5.1, Spec S3 ; Tests TC-NOM-04, TC-ERR-08).
  • Re-horodatage : éligibilité via rehorodatageLeadTime + traçabilité supersedesTstId (Spec INV-265-06, Spec §5.5 F4, Spec S4 ; Tests TC-NOM-05).
  • Trusted List ETSI : TTL/cache + dégradation si refresh impossible au-delà du TTL (Spec INV-265-07, Spec §5.2/§5.3, Spec S5 ; Tests TC-NOM-06, TC-ERR-04).
  • Formats/validation stricts : enums case-sensitive, UUIDv4, hex normalisé, rejet explicite si invalide (Spec INV-265-12, Spec §5.1 ; Tests TC-ERR-07, tests négatifs TC-NEG-02/04/06).
  • Idempotence/retry-safe post-commit : crash post-commit rattrapé sans duplication logique (Spec INV-265-09, Spec §5.6 ; Tests TC-ERR-11).
  • Chiffrement at-rest des secrets temporaires : absence de secret en clair au repos (Spec INV-265-08, CA-09, Spec S7 ; Tests TC-ERR-09, TC-NEG-08).
  • Machine d’états : transitions non listées interdites (Spec INV-265-11, Spec §5.4 ; Tests TC-ERR-12, TC-NR-03, TC-NEG-07).

3. Divergences

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

  • DIV-01 : Politique de blocage d’émission TST en DEGRADED_REVOCATION traitée comme absolue dans les tests, ambiguë/conditionnelle dans la spécification
  • Source A (Spécification) : “Échec OCSP/CRL (…) -> état DEGRADED_REVOCATION (…) blocage émission TST si politique fail-closed active.” (Spec §6) ; les invariants listent l’état mais ne posent pas explicitement “blocage toujours” pour DEGRADED_REVOCATION (Spec INV-265-02).
  • Source B (Tests) : “OCSP REVOKED / CRL LISTED / OCSP UNKNOWN => (…) Émission TST interdite / Aucun TST nouveau n’est émis.” (Tests TC-ERR-02, TC-ERR-03, Tests §4).

  • Impact : si la politique “fail-closed active” n’est pas définie/figée, l’acceptation test (et la conformité attendue) diverge : implémentation potentiellement conforme à la spec mais rejetée par les tests, ou inversement.

  • DIV-02 : NTS/NTP mentionné comme objectif/périmètre, mais non spécifié ni testé côté NTP

  • Source A (Spécification) : “surveillance NTS/NTP” (Spec §1) et “Monitoring NTS/NTP avec mode fail-closed” (Spec §2 Inclus), mais les invariants/flux détaillent NTS (Spec INV-265-01, Spec F2) sans contrat explicite NTP.
  • Source B (Tests) : tous les scénarios et observables parlent uniquement de NTS (Tests TC-NOM-01/02, TC-ERR-01 ; Tests §8).

  • Impact : risque de trou contractuel (NTP implicite) ou de sur-promesse (objectif NTS/NTP) non démontrable en gate.

  • DIV-03 : Exigences d’observabilité “événement signé” et “motif normé” présentes dans les tests mais pas contractualisées dans la spécification

  • Source A (Spécification) : exige métriques/alertes de manière générale (Spec §5.5, §6, §7) et un “rapport d’audit signé” pour CA-01 (Spec CA-01), sans exiger que les alertes critiques soient “signées”.
  • Source B (Tests) : impose “Événement signé / horodaté : alertes critiques” et “codes de refus (…) + motif normé” (Tests §8).

  • Impact : les tests introduisent des obligations potentiellement bloquantes (signature/normalisation) qui peuvent être jugées hors-contrat par rapport à la spec, ou au contraire attendues en audit sans base formelle dans la spec.

  • DIV-04 : Périmètre “Aucune contrainte inter-module” vs attentes de surface API/exports probatoires dans les tests

  • Source A (Spécification) : “Aucune contrainte inter-module applicable” (Spec §5.8) et exclusions de provisioning (Spec §2 Exclu).
  • Source B (Tests) : requiert “Réponse API : codes de refus (…)”, “Export probatoire : rapport CI, rapport audit Prolog, preuve chiffrement, liste TST” (Tests §8).
  • Impact : ambiguïté sur l’endroit où vivent ces exports/réponses (module TSA vs interfaces externes) et si cela constitue une contrainte inter-module implicite non déclarée.

4. Zones d'ombre

  • “Délai contractuel” de traitement re-horodatage : la spec déclenche une alerte si non traité “dans le délai contractuel” (Spec INV-265-06), et les tests l’utilisent (Tests TC-ERR-10), mais aucune valeur/contrat temporel n’est défini (ni paramètre, ni SLA dédié).
  • Liste normative des serveurs NTS de référence : explicitement ouverte (Spec §10.2) et reprise comme non testable (Tests §9).
  • Politique d’exceptions en mode dégradé : ouverte dans la spec (Spec §10.2 “exceptions contrôlées”) et signalée comme majeure/non testable (Tests §9) ; elle conditionne directement DIV-01.
  • Nomenclature exacte des métriques (noms/labels/cardinalité) : non figée (Spec §10.2) et signalée non testable (Tests §9), alors que les tests demandent un minimum d’observabilité (Tests §8) sans définir de noms contractuels.
  • Paramètre maxDegradedDuration : présent dans les SLA (Spec §5.3) mais non défini dans la table des paramètres (Spec §5.2) et non couvert par des tests dédiés.
  • États/combinaison d’états : un seul tsaServiceState est défini (Spec §5.1/§5.4). Aucune règle n’explicite la gestion d’événements simultanés (ex: NTS KO pendant révocation), alors que la machine d’états interdit les transitions directes entre états dégradés (Spec §5.4 ; Tests TC-ERR-12).
  • Référence épique : absente dans la spec (Spec Références) et remplacée par un placeholder dans les tests (Tests §1 “EPIC-XX”).

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

Note: conformément à ton instruction “NE PAS accéder au filesystem”, je ne peux pas sauvegarder le fichier. Voici le contenu à copier tel quel dans ProbatioVault-backend/docs/epics/legal-compliance/PD-265-monitoring-tsa-lifecycle/PD-265-confrontation-step3.md.