PD-265 — Specification Review¶

Auditeur : Claude (Opus 4.6) Date : 2026-03-02 Documents d'entrée : PD-265-specification.md, PD-265-tests.md Domaine : legal-compliance (backend — monitoring TSA RFC 3161)

Synthèse¶

Points identifiés¶

POINT-01¶

Type : Contradiction Référence : INV-265-11 (§4) vs INV-265-01 / INV-265-02 / INV-265-05 / INV-265-07 (§4), §5.4 machine d'états, TC-ERR-12 Description : La machine d'états est mono-état : chaque état DEGRADED_* ne peut transiter que vers HEALTHY (§5.4). INV-265-11 déclare ce modèle exhaustif et TC-ERR-12 valide explicitement le refus de DEGRADED_NTS -> DEGRADED_TRUSTLIST. Or INV-265-01 impose DEGRADED_NTS si NTS échoue, INV-265-02 impose DEGRADED_REVOCATION si OCSP ≠ GOOD, etc. — chaque invariant utilise « DOIT ». Si le système est en DEGRADED_NTS et qu'une vérification OCSP retourne REVOKED, INV-265-02 exige le passage à DEGRADED_REVOCATION mais INV-265-11 l'interdit. Les deux invariants ne peuvent pas être satisfaits simultanément en cas de défaillances multiples concurrentes. Impact : En production, les défaillances multiples sont courantes (panne réseau affectant NTS + OCSP + Trusted List). Le système ne pourrait signaler qu'une seule défaillance, masquant les autres — violation directe de la traçabilité et de la conformité. Gravité : Bloquant

POINT-02¶

Type : Ambiguïté Référence : §5.5 F1/F2/F5/F6, §6 cas d'erreur, INV-265-01 (émission bloquée), INV-265-02 (§6 « émission TST interdite ») Description : Le blocage d'émission de TST est explicitement spécifié pour DEGRADED_NTS (INV-265-01) et DEGRADED_REVOCATION (§6). En revanche, aucune règle ne précise si l'émission de TST est autorisée ou interdite en état DEGRADED_TRUSTLIST, DEGRADED_KEY_LIFECYCLE ou MAINTENANCE. L'absence de spécification pour ces trois états constitue une ambiguïté opérationnelle. Impact : Un TST signé par une autorité retirée de la Trusted List ETSI (DEGRADED_TRUSTLIST) ou par une clé dont la rotation est en retard (DEGRADED_KEY_LIFECYCLE) pourrait être non conforme eIDAS. L'absence de règle empêche un implémenteur tiers de décider. Gravité : Bloquant

POINT-03¶

Type : Ambiguïté Référence : INV-265-06 (§4), §5.2 paramètre rehorodatageLeadTime, TC-ERR-10 Description : INV-265-06 stipule « absence de traitement dans le délai contractuel => alerte critique ». TC-ERR-10 teste « le délai contractuel de traitement est dépassé sans re-horodatage ». Mais aucun paramètre ne définit ce « délai contractuel de traitement ». Le rehorodatageLeadTime définit la fenêtre d'éligibilité (45 jours par défaut), pas le délai maximum pour exécuter le re-horodatage d'un TST éligible une fois détecté. Sans valeur numérique, l'invariant est non testable de manière déterministe. Impact : TC-ERR-10 ne peut pas être implémenté sans inventer un seuil. L'alerte critique ne peut pas être déclenchée sur critère objectif. Gravité : Bloquant

POINT-04¶

Type : Contradiction Référence : §5.2 paramètre rehorodatageBatchSize (« Clamp à max »), INV-265-12 (§4), CA-08 Description : INV-265-12 déclare « Aucune hypothèse implicite de format de données n'est autorisée ; tous formats sont définis en §5.1 ». CA-08 exige « Paramètres hors bornes numériques rejetés ». Or le paramètre rehorodatageBatchSize en §5.2 spécifie « Clamp à max si dépassement runtime » au lieu de « Rejet config » comme les 13 autres paramètres. TC-NEG-05 valide ce comportement de clamp. La spec contredit son propre invariant (INV-265-12 : pas d'hypothèse implicite) en traitant silencieusement un dépassement au lieu de le rejeter. Impact : Un implémenteur appliquant INV-265-12 strictement rejetterait la valeur ; un implémenteur suivant §5.2 la clamperait. Comportement contradictoire. Gravité : Majeur

POINT-05¶

Type : Incohérence Spec↔Tests Référence : §5.4 transitions, TC-NOM-03 (retour DEGRADED_REVOCATION -> HEALTHY) Description : La spec §5.4 définit la condition de retour : « DEGRADED_REVOCATION -> HEALTHY : AUTORISÉE si OCSP=GOOD et CRL valide non listée ». TC-NOM-03 ajoute une condition absente de la spec : « CRL retourne NOT_LISTED et fraîcheur <= crlMaxAge ». La contrainte de fraîcheur CRL pour le retour à HEALTHY n'est pas spécifiée dans la machine d'états. Impact : Le test impose une condition plus restrictive que la spec. Un implémenteur suivant la spec seul ne vérifierait pas la fraîcheur CRL au retour. Gravité : Majeur

POINT-06¶

Type : Incohérence Spec↔Tests Référence : INV-265-10 -> CA-04 -> TC-NOM-07, matrice de couverture §2 Description : La matrice de couverture des tests associe INV-265-10 (« tests contractuels sign+verify roundtrip en CI sont obligatoires ») au critère CA-04 (« Rotation clé HSM avec labels conformes pv-tsa-signing-YYYY »). Ce sont deux exigences distinctes : le roundtrip cryptographique et la rotation de clé. Le mapping INV-265-10 -> CA-04 est incorrect ; INV-265-10 devrait être lié à un critère d'acceptation dédié ou au minimum à une ligne séparée. Impact : Un auditeur vérifiant CA-04 pourrait conclure que le roundtrip est couvert par la rotation, ou inversement qu'il manque un CA pour le roundtrip. Gravité : Majeur

POINT-07¶

Type : Hypothèse dangereuse Référence : §5.4 retour DEGRADED_NTS -> HEALTHY, §5.2 ntsCheckInterval, §5.3 maxDegradedDuration Description : Le retour de DEGRADED_NTS à HEALTHY requiert « 2 contrôles consécutifs » conformes (§5.4). Le temps minimum de retour est donc 2 × ntsCheckInterval. Avec ntsCheckInterval max = 3600s, le retour minimum est 7200s (2h). Or maxDegradedDuration par défaut est 2h (7200s) et son minimum est 5min. Pour ntsCheckInterval >= 3601s, le système atteint mécaniquement l'escalade critique avant de pouvoir mathématiquement revenir à HEALTHY. Impact : Configuration valide selon les bornes individuelles mais opérationnellement impossible. Aucune contrainte croisée entre ntsCheckInterval et maxDegradedDuration n'est spécifiée. Gravité : Bloquant

POINT-08¶

Type : Ambiguïté Référence : §5.4 état MAINTENANCE, §5.5, §4 invariants Description : L'état MAINTENANCE est listé comme état valide de la machine tsaServiceState. Les transitions HEALTHY -> MAINTENANCE et MAINTENANCE -> HEALTHY sont autorisées. Mais aucun invariant, critère d'acceptation ou flux fonctionnel ne définit les restrictions applicables en mode maintenance : émission TST autorisée ou non, contrôles périodiques actifs ou suspendus, clés accessibles ou verrouillées. Impact : L'état MAINTENANCE est une coquille vide dans la spec. Un implémenteur ne peut pas déterminer le comportement attendu. Gravité : Majeur

POINT-09¶

Type : Ambiguïté Référence : INV-265-06 (§4), §5.5 F3, §5.5 F4 Description : Le terme « archivage logique » est utilisé pour l'ancienne clé après rotation (§5.5 F3, TC-NOM-04) sans définition. La spec ne précise pas : (a) si la clé archivée reste accessible pour vérification de TST existants, (b) si elle est supprimée du HSM, © quel label elle porte après archivage, (d) si elle peut être ré-activée. Impact : Le re-horodatage (F4) pourrait nécessiter l'ancienne clé pour vérifier les TST avant ré-émission. Si « archivage logique » signifie suppression, le flux F4 est cassé. Gravité : Majeur

POINT-10¶

Type : Incohérence Spec↔Tests Référence : §5.4 transitions, TC-NOM-02, TC-ERR-12, §2 matrice de couverture Description : Aucun test ne couvre l'entrée et la sortie de l'état MAINTENANCE (HEALTHY -> MAINTENANCE, MAINTENANCE -> HEALTHY). TC-NEG-07 vérifie qu'une transition illégale depuis MAINTENANCE est refusée, mais les transitions légitimes ne sont pas testées. La matrice §2 ne mentionne aucun TC pour les transitions MAINTENANCE. Impact : L'état MAINTENANCE est partiellement couvert (test négatif seul, pas de test nominal). Gravité : Mineur

POINT-11¶

Type : Ambiguïté Référence : §5.3 SLA maxDegradedDuration, §5.4 machine d'états Description : maxDegradedDuration (défaut 2h) déclenche « Escalade critique exploitation » au dépassement. La spec ne précise pas : (a) si ce SLA s'applique à chaque état dégradé indépendamment, (b) au temps cumulé dans tout état dégradé, © ce que « escalade critique exploitation » implique concrètement (notification ? passage automatique en MAINTENANCE ? intervention humaine obligatoire ?). Impact : Sans définition de l'action d'escalade, le SLA est non testable et non auditable. Gravité : Majeur

POINT-12¶

Type : Ambiguïté Référence : §6 cas d'erreur (alertes), §8 observabilité, CA-02, CA-03, CA-06 Description : Le terme « alerte critique » est utilisé dans 5 contextes différents (NTS, révocation, re-horodatage, Trusted List, rotation) sans définition du mécanisme : format, canal de diffusion, consommateur cible, acquittement. §8 mentionne « événement signé / horodaté » pour certaines alertes mais pas toutes. La distinction entre « alerte critique » et « métrique d'état » n'est pas formalisée. Impact : Un implémenteur ne peut pas distinguer une alerte d'une métrique. Le test d'observabilité (§8) est incomplet. Gravité : Mineur

POINT-13¶

Type : Risque sécu/conformité Référence : §5.4 retour DEGRADED_REVOCATION -> HEALTHY, §5.2 ocspCheckInterval (max 86400s) Description : Le retour de DEGRADED_REVOCATION à HEALTHY est conditionné à « OCSP=GOOD et CRL valide non listée ». Mais les contrôles sont périodiques (ocspCheckInterval jusqu'à 86400s = 24h). Entre deux vérifications, si un certificat est rétabli (CRL mise à jour), le système reste en DEGRADED_REVOCATION jusqu'au prochain cycle. Inversement, après un retour à HEALTHY, si le certificat est re-révoqué, il faut attendre le prochain cycle pour détecter la régression. Impact : Fenêtre de divergence état/réalité pouvant atteindre 24h. L'absence de vérification immédiate sur événement ou de contrôle renforcé en sortie de dégradation crée un risque de conformité temporel. Gravité : Mineur

POINT-14¶

Type : Hypothèse dangereuse Référence : INV-265-06 (§4), §5.5 F4, INV-265-05, §5.4 état DEGRADED_KEY_LIFECYCLE Description : Le re-horodatage (F4) requiert l'émission d'un nouveau TST, donc une signature avec la clé TSA active. Si le système est en DEGRADED_KEY_LIFECYCLE (clé active dont l'âge dépasse keyRotationPeriod), la spec ne précise pas si le re-horodatage est autorisé avec cette clé « périmée » ou s'il est bloqué. Bloquer le re-horodatage empêche de protéger les TST expirants ; l'autoriser utilise une clé dont la rotation est en retard. Impact : Dilemme opérationnel non résolu entre continuité de conformité long terme (INV-265-06) et robustesse cryptographique (INV-265-05). Gravité : Mineur

Récapitulatif par gravité¶

Bloquants (4)¶

Majeurs (6)¶

Mineurs (4)¶