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 (SPÉCIFICATION CORRIGÉE COMPLÈTE)
  • Tests : PD-265 — Scénarios de tests contractuels (TESTS CORRIGÉS COMPLETS)

2. Convergences

  • Fail-closed sur NTS : blocage de l’émission de TST dès que NTS est actif (Spec INV-265-01, §5.4 ; Tests matrice INV-265-01 + TC-NOM-01, TC-ERR-01).
  • Révocation = dégradation bloquante : REVOCATION activé si OCSP≠GOOD / CRL≠NOT_LISTED / indisponible / fraîcheur dépassée, et émission TST interdite (Spec INV-265-02, §5.4 ; Tests TC-ERR-02, TC-ERR-03, TC-NOM-03).
  • Machine d’états dérivée des flags : tsaServiceDegradationFlags source de vérité, tsaServiceState dérivé (Spec §5.4, INV-265-11 ; Tests TC-ERR-12, TC-NOM-10).
  • RBAC MAINTENANCE : toggle réservé au rôle TSA_OPERATOR, tentatives non autorisées refusées et journalisées (Spec INV-265-14, §5.4, §5.9 ; Tests TC-NOM-09, TC-NEG-09).
  • Contraintes de config et formats stricts : bornes numériques et formats (UUIDv4, enums case-sensitive, regex labels) rejetés explicitement (Spec INV-265-12, §5.1/§5.2 ; Tests TC-ERR-06, TC-ERR-07, TC-CROSS-01, TC-CROSS-02, tests négatifs).
  • Trusted List ETSI : TTL/cache + refresh, absence d’autorité => TRUSTLIST et état dégradé (Spec INV-265-07, §5.4 ; Tests TC-ERR-04, TC-NOM-06, TC-NOM-CLEAR-TRUSTLIST).
  • Rotation clés + convention de labels : pv-tsa-signing-YYYY obligatoire, CI fail si non conforme (Spec INV-265-03/04, §5.5 ; Tests TC-ERR-08, TC-NOM-04).
  • Re-horodatage : éligibilité via rehorodatageLeadTime, lien supersedesTstId, alerte critique si rehorodatageProcessingDeadline dépassé (Spec INV-265-06, §5.3/§5.4/§5.9 ; Tests TC-NOM-05, TC-ERR-10).
  • Idempotence / crash post-commit : traitements async retry-safe, rattrapage sans duplication logique (Spec INV-265-09, §5.6 ; Tests TC-ERR-11).

3. Divergences

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

  • DIV-01 : Alerte critique NTS sur dérive d’offset (mesure valide)
  • Source A (Spécification) : offset NTS > seuil => flag NTS + alerte critique immédiate (événement signé/horodaté) (Spec §6 “Offset NTS > seuil … alerte critique immédiate”, + §5.9 “alertes critiques” avec reasonCode incluant NTS_OFFSET).
  • Source B (Tests) : TC-NOM-01 (offset=150ms) exige état/flags + refus TST + “Un événement d’état horodaté est tracé”, sans exigence d’alerte critique immédiate ni PV_TSA_CRITICAL_ALERT (Tests TC-NOM-01).

  • Impact : risque de non-conformité contractuelle sur la criticité “immédiate” et le canal probatoire pour le cas nominal “offset > seuil”.

  • DIV-02 : Criticité / canal probatoire lors d’un incident TRUSTLIST (TTL dépassé + refresh KO)

  • Source A (Spécification) : les alertes critiques incluent les cas “trustlist invalide” (Spec §5.9 “toute alerte critique … trustlist invalide … événement signé/horodaté”).
  • Source B (Tests) : TC-ERR-04 attend “Alerte de conformité est exposée” et “Alerte … exposée”, sans exiger explicitement un événement CRITICAL signé/horodaté type PV_TSA_CRITICAL_ALERT pour ce scénario (Tests TC-ERR-04). (La section “Observabilité requise” cite bien “trustlist TTL dépassé” dans la liste des alertes critiques, mais TC-ERR-04 ne l’impose pas au niveau du scénario.)

  • Impact : ambiguïté opérationnelle sur la sévérité attendue et le caractère probatoire (signature/horodatage) du signal d’alerte trustlist.

  • DIV-03 : Référence d’epic

  • Source A (Spécification) : “Epic : Référence épique non renseignée” (Spec Références + §10.2).
  • Source B (Tests) : “Epic : EPIC-XX” (Tests §1 Références).
  • Impact : traçabilité documentaire incohérente (lien epic), susceptible de bloquer l’audit/alignement workflow.

4. Zones d'ombre

  • Signature/JCS des événements (hors rapport d’audit) : la spec impose JCS (RFC 8785) + signature + signatureKeyId pour événements critiques (PV_TSA_CRITICAL_ALERT) et événements de transition d’état (PV_TSA_STATE_TRANSITION) (Spec INV-265-13, §5.9). Les tests valident explicitement le rapport d’audit (TC-NOM-08) mais ne définissent pas un scénario vérifiant la vérifiabilité cryptographique des événements PV_TSA_CRITICAL_ALERT et PV_TSA_STATE_TRANSITION (présence signatureKeyId, signature valide sur payload JCS) de bout en bout.
  • Couverture “refusalReasonCode” complète : les scénarios détaillent MAINTENANCE et NTS_DEGRADED (Tests TC-NOM-09, TC-NOM-01), mais l’équivalent explicite pour REVOCATION_DEGRADED, TRUSTLIST_DEGRADED, KEY_LIFECYCLE_DEGRADED, COMPOSITE_DEGRADED n’est pas décrit en scénario Given/When/Then dédié (Spec §5.4 contrat de refus ; Tests matrice/NR parlent de stabilité mais sans scénario détaillé par état).
  • Politique re-horodatage en DEGRADED_KEY_LIFECYCLE : la spec autorise le re-horodatage uniquement si KEY_LIFECYCLE est le seul flag actif et si cert/TL restent OK (Spec §5.4, “Politique de re-horodatage”). Les tests ne couvrent pas ce cas conditionnel (autorisé si flag unique vs bloqué si composite).
  • Ordonnancement/normalisation de tsaServiceDegradationFlags : la spec contractualise “liste ordonnée triée lexicographiquement” et contraintes de format/doublons (Spec §5.1). Les tests manipulent plutôt les flags comme un ensemble (“contient …”), sans test dédié sur l’ordre/absence de doublons / rejet d’élément inconnu.
  • Port implicite NTS (4460) / validation FQDN+port : la spec précise “port implicite 4460 si non précisé” (Spec §5.2). Les tests valident MIN 2 serveurs et usage de la liste, mais pas le comportement “port implicite” ni les cas d’entrées avec/sans port.
  • “Politique détaillée d’exceptions en mode dégradé” : les tests indiquent une ambiguïté résiduelle (Tests §9), et la spec liste encore un point à clarifier (Spec §10.2) alors même que §5.4 décrit une politique explicite (fail-closed + exception re-horodatage limitée en KEY_LIFECYCLE). Le périmètre exact de ce “reste à clarifier” demeure flou (documents non alignés sur ce qui est encore ouvert vs déjà contractuel).

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 : non cochée volontairement — ce rapport constate des faits (convergences/divergences/zones d’ombre) et ne prend pas position.

Je ne peux pas sauvegarder sur le filesystem (instruction “NE PAS accéder au filesystem”). Tu peux coller tel quel ce contenu dans : /Users/loic/Developpement/ProbatioVault/ProbatioVault-backend/docs/epics/legal-compliance/PD-265-monitoring-tsa-lifecycle/PD-265-confrontation-step3.md