PD-265 — Specification Review (v3)¶

Type : Ambiguïté
Référence : Spec §5.2 (ntsReferenceServers MIN 2), §5.4 (condition NTS), INV-265-01
Description : La spec contractualise ntsReferenceServers (MIN 2, MAX 10 serveurs) mais ne définit pas la logique d'agrégation des mesures multi-serveurs. Avec 2+ serveurs, plusieurs résultats sont possibles : serveur A offset=50ms, serveur B offset=150ms (seuil=100ms). La condition NTS est évaluée sur un scalaire unique « ntsOffsetMs » (§5.1) — le mécanisme de réduction (moyenne, médiane, pire cas, tout-ou-rien, majorité) n'est pas spécifié. TC-NOM-01 et TC-NOM-11 testent respectivement un offset unique et la restriction aux serveurs autorisés, sans couvrir le cas de désaccord inter-serveurs.
Impact : Deux implémentations conformes pourraient donner des résultats d'état différents pour les mêmes mesures. Risque de faux négatif (pas de dégradation malgré un serveur compromis) ou faux positif (dégradation sur un seul serveur temporairement instable). Criticité renforcée par le fait que NTS est fail-closed.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Spec §5.5 (SLA keyRetiredToArchivedDelay, keyArchivedToDestroyedDelay), §5.3, §6
Description : Les corrections V3 introduisent deux SLA post-rotation : RETIRED → ARCHIVED (défaut 90j) et ARCHIVED → DESTROYED (défaut 365j). La spec §5.5 dit « ne peut pas durer au-delà ». Mais aucun mécanisme d'enforcement n'est défini : (a) pas de flag de dégradation associé, (b) pas d'alerte critique listée en §5.9, (c) pas de reasonCode dans la nomenclature des événements, (d) pas de métrique de surveillance (âge par état de clé). §6 ne mentionne pas le dépassement de ces SLA comme cas d'erreur. Aucun test ne couvre le dépassement de keyRetiredToArchivedDelay ou keyArchivedToDestroyedDelay.
Impact : Les SLA sont déclaratifs mais inapplicables — aucun observable ne permet de détecter ni de prouver un dépassement. Une clé RETIRED pourrait persister indéfiniment sans alerte.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Spec §5.4 (politique re-horodatage par état), Tests TC-NOM-05
Description : La spec définit 7 politiques de re-horodatage explicites (une par état) : AUTORISÉ en HEALTHY, BLOQUÉ en DEGRADED_NTS/REVOCATION/TRUSTLIST/composite/MAINTENANCE, et AUTORISÉ UNIQUEMENT sous conditions en DEGRADED_KEY_LIFECYCLE (flag unique + cert valide + TL valide). Or TC-NOM-05 (seul test nominal de re-horodatage) ne spécifie pas de précondition d'état — il est implicitement en HEALTHY. Aucun test ne couvre : (a) le re-horodatage autorisé en DEGRADED_KEY_LIFECYCLE (path conditionnel critique), (b) le blocage du re-horodatage en DEGRADED_NTS/REVOCATION/TRUSTLIST/composite, (c) le refus de re-horodatage en DEGRADED_KEY_LIFECYCLE quand la condition n'est pas remplie (ex: KEY_LIFECYCLE + REVOCATION simultanés).
Impact : Les 6 chemins non-HEALTHY de la politique de re-horodatage ne sont pas vérifiés. Le path conditionnel DEGRADED_KEY_LIFECYCLE est particulièrement sensible (autorisation sous conditions strictes).
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Spec §5.5 (archivage logique) vs Tests TC-NOM-04
Description : TC-NOM-04 THEN stipule « L'ancienne clé passe en archivage logique (ACTIVE -> RETIRED -> ARCHIVED selon procédure) ». La spec V3 définit clairement RETIRED et ARCHIVED comme des états distincts avec des SLA temporels différents (keyRetiredToArchivedDelay=90j). Le test TC-NOM-04 vérifie la rotation en une seule exécution, mais la transition complète ACTIVE→RETIRED→ARCHIVED s'étale sur des jours/mois. Le THEN devrait vérifier uniquement ACTIVE→RETIRED.
Impact : Le test est structurellement impossible à exécuter tel que formulé (la transition complète prend 90+ jours).
Gravité : Mineur

Type : Hypothèse dangereuse
Référence : Spec §5.2 (contrainte croisée maxDegradedDuration vs ntsCheckInterval)
Description : La contrainte croisée « maxDegradedDuration >= 3 × ntsCheckInterval » protège uniquement le ratio avec l'intervalle NTS (défaut 60s). Pour les flags REVOCATION (ocspCheckInterval=3600s), TRUSTLIST (trustedListRefreshInterval=86400s) et KEY_LIFECYCLE (pas d'intervalle de contrôle explicite), le ratio n'est pas protégé. Avec les valeurs par défaut, maxDegradedDuration=7200s ne permet que 2 vérifications OCSP et 0.08 refresh TL avant escalade critique.
Impact : Escalades critiques prématurées pour les flags à intervalle lent. L'opérateur serait forcé d'augmenter maxDegradedDuration globalement pour accommoder les flags lents, réduisant la protection pour NTS.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Spec §5.4 (sortie MAINTENANCE) vs Tests TC-NOM-10
Description : TC-NOM-10 couvre la sortie MAINTENANCE → DEGRADED (flags actifs). La spec dit « l'état de sortie est recalculé depuis les flags ». Le cas flags=vide → HEALTHY (sortie nominale après maintenance sans incident) n'est couvert par aucun test.
Impact : Le chemin MAINTENANCE → HEALTHY pourrait ne pas être implémenté. Risque faible (path trivial).
Gravité : Mineur

Type : Ambiguïté
Référence : Spec §5.2 (rehorodatageBatchSize), Tests TC-NEG-05
Description : §5.2 indique « Rejet explicite si dépassement runtime/config (pas de clamp) ». Le terme « runtime » est ambigu : validation de la valeur de configuration au chargement, ou rejet à l'exécution si un lot de TST éligibles dépasse la taille configurée. Si c'est un comportement d'exécution, le traitement des lots excédentaires (pagination ? rejet complet du batch ? alerte ?) n'est pas spécifié.
Impact : Comportement indéterminé quand le nombre de TST éligibles dépasse la taille de batch.
Gravité : Mineur

Type : Hypothèse dangereuse
Référence : Spec §5.4 (politique re-horodatage en DEGRADED_KEY_LIFECYCLE)
Description : Le re-horodatage autorisé en DEGRADED_KEY_LIFECYCLE signe avec une clé dont l'âge dépasse keyRotationPeriod. Un auditeur eIDAS pourrait contester la valeur probatoire du TST résultant. Toutefois, la spec accepte explicitement ce compromis (continuité de vérifiabilité > blocage total).
Impact : TST de re-horodatage potentiellement contestables en audit. Risque explicitement accepté par la spécification.
Gravité : Mineur

Type : Hypothèse dangereuse
Référence : Spec §5.4 (maxDegradedDuration), monitoring NTS
Description : La mesure de durée de dégradation pour le flag NTS repose sur l'horloge locale. Or, le flag NTS est précisément activé quand la synchronisation temporelle est défaillante. L'hypothèse implicite est que la dérive NTS (millisecondes) n'affecte pas significativement la mesure de maxDegradedDuration (heures). Cette hypothèse est raisonnable mais non documentée.
Impact : Risque théorique faible. L'hypothèse devrait être explicitée.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Spec §5.1 (tsaServiceDegradationFlags format) vs Tests
Description : §5.1 définit tsaServiceDegradationFlags comme « liste ordonnée, triées lexicographiquement » avec rejet si « format non conforme / doublons / élément inconnu ». Aucun test ne vérifie : (a) le rejet de doublons dans les flags, (b) le rejet d'un élément inconnu, (c) le respect du tri lexicographique.
Impact : Des flags mal formés pourraient corrompre la dérivation de tsaServiceState. L'impact est atténué si tsaServiceDegradationFlags est calculé en interne (pas d'entrée externe).
Gravité : Mineur

Type : Ambiguïté
Référence : Spec §6 (export probatoire), Tests TC-ERR-10
Description : §6 mentionne « export probatoire listant les TST en retard » et TC-ERR-10 exige « Les TST en retard sont listés nominativement dans l'export probatoire ». Le format de cet export n'est défini nulle part — §5.9 couvre les événements d'alerte critique JSON mais pas les exports probatoires.
Impact : L'implémentation ne peut pas produire un export conforme sans spécification de format.
Gravité : Mineur