PD-265 — Monitoring TSA et cycle de vie des clés RFC 3161¶
1. Contexte¶
La vérification formelle RFC 3161 est complète. L'audit Prolog completeness (⅙ OK) a identifié 5 mécanismes opérationnels manquants nécessaires à la robustesse en production :
- Monitoring NTS (synchronisation NTP/NTS)
- Révocation CRL/OCSP du certificat TSA
- Rotation des clés HSM dédiées TSA
- Re-horodatage avant expiration des certificats
- Trusted List ETSI (vérification périodique)
Dépendances résolues :
- PD-55 (worker ancrage blockchain) — infrastructure TSA en place
- PD-264 (nonce anti-rejeu) — terminé (intégré en production)
- PD-7 (HSM FIPS 140-2 Level 3) — cluster HSM opérationnel
2. Objectif¶
Implémenter les mécanismes opérationnels de monitoring et de cycle de vie des clés pour le service TSA RFC 3161, afin d'atteindre un audit Prolog completeness >= ⅚ OK et garantir la robustesse du service en production.
3. Périmètre fonctionnel¶
3.1 CRL/OCSP Revocation Cron¶
Vérification périodique de la révocation du certificat TSA (RFC 3161 §4.1).
- Interrogation CRL et OCSP du certificat TSA courant
- Alerting si certificat révoqué ou proche de l'expiration
- Métriques Prometheus exposées (statut, latence, dernière vérification)
3.2 NTS Monitoring Cron¶
Surveillance continue de la synchronisation NTP/NTS (§2.1.1).
- Vérification de l'offset NTP/NTS par rapport aux serveurs de référence
- Seuil d'alerte : offset > 100ms → alerte Prometheus/Grafana
- Fail-closed (learning PD-39) : si le monitoring NTS échoue, le service TSA DOIT être dégradé (pas de silencieux)
3.3 Rotation des clés HSM¶
Cron de rotation planifiée des clés HSM dédiées TSA (§4.3).
- Labels dédiés :
pv-tsa-signing-YYYY(production),pv-test-tsa-*(tests) - Rotation : génération nouvelle clé → transfert progressif → archivage ancienne clé
- Métriques : âge de la clé active, nombre de signatures, date de prochaine rotation
3.4 Re-horodatage (re-timestamp)¶
Mécanisme pour re-horodater les TST avant expiration du certificat TSA (§4.3 era).
- Détection des TST dont le certificat émetteur approche de l'expiration
- Re-horodatage automatique avec le nouveau certificat/clé
- Traçabilité : lien entre ancien TST et nouveau TST
3.5 Label HSM dédié TSA¶
Création et utilisation de pv-tsa-signing-YYYY pour distinguer les clés TSA des autres clés HSM.
- Convention de nommage stricte (learning PD-63 / CLAUDE.md) :
pv-tsa-signing-YYYY - Tests avec
pv-test-tsa-*(exclus de la vérification de rotation) - Vérification en CI : tout label hors convention → échec pipeline
3.6 Trusted List ETSI¶
Vérification périodique de la Trusted List européenne (liste de confiance eIDAS).
- Téléchargement et parsing de la Trusted List EU
- Vérification que le certificat TSA courant est émis par une autorité de confiance listée
- Alerting si l'autorité émettrice est retirée de la liste
- Cache local de la Trusted List avec TTL configurable
4. Infrastructure existante¶
| Composant | État |
|---|---|
| Prometheus | Opérationnel |
| Grafana | Opérationnel |
| Cluster HSM (CloudHSM) | Opérationnel (PD-7) |
| Service TSA RFC 3161 | Opérationnel (PD-55, PD-264) |
| Worker ancrage blockchain | Opérationnel (PD-55) |
→ PD-265 ajoute des métriques et des crons. Pas de nouvelle infrastructure à provisionner.
5. Critères d'acceptation¶
| ID | Critère |
|---|---|
| CA-01 | Audit Prolog completeness RFC 3161 >= ⅚ OK |
| CA-02 | Cron revocation CRL/OCSP exécutable et testé (vérification certificat TSA) |
| CA-03 | Cron NTS monitoring avec alerting Prometheus/Grafana si offset > 100ms |
| CA-04 | Cron rotation clé HSM avec label pv-tsa-signing-YYYY documenté |
| CA-05 | Service ou cron de re-horodatage pour les TST proches de l'expiration certificat |
| CA-06 | Pipeline CI vert (Sonar QG PASSED) |
6. Contraintes et alertes (learnings injectés)¶
| Learning | Source | Impact |
|---|---|---|
| Fail-closed obligatoire pour NTS auth | PD-39 | Pas de default permissif — dégradation explicite si monitoring échoue |
| Tests contractuels HSM en CI obligatoires | PD-7 | Les tests de rotation DOIVENT tourner en CI avant review |
| Migration DDL requiert cluster de constats | PD-264 | Si nouvelles tables/colonnes → spec doit détailler migration/trigger/worker |
| Vérification indépendante = infra séparée | PD-37 | Ne pas dépendre du HSM pour vérifier les signatures (table public keys) |
Labels HSM stricts pv-test-* | PD-63 | Clés éphémères de test DOIVENT utiliser le préfixe pv-test-tsa-* |
crypto.verify(null, hash, key, sig) | PD-282 | Pas de createVerify pour vérification ECDSA HSM (double-hash) |
| Roundtrip sign-verify obligatoire | PD-282 | Test contractuel sign+verify sur les mêmes données |
7. Hors périmètre¶
- Modification du worker d'ancrage blockchain (PD-55)
- Modification du mécanisme de nonce anti-rejeu (PD-264)
- Provisionnement Prometheus/Grafana (déjà opérationnel)
- Migration du cluster HSM (PD-7 déjà en place)
8. Fréquences des crons¶
Les intervalles seront définis par le spécificateur en s'appuyant sur les recommandations RFC. Les valeurs proposées serviront de référence et pourront être ajustées en revue.