Résumé

  • La RFC 3161 lie une empreinte à une heure, une politique et une clé ; le jeton ne contient pas le dossier démontrant que l’autorité a réellement appliqué cette politique.
  • La RFC 3628 distinguait déjà le « quoi » de la politique du « comment » de la déclaration de pratiques. L’ETSI EN 319 421 V1.3.1 conserve cette architecture en 2025.
  • Une décision de confiance défendable doit joindre au jeton la version des pratiques, la chaîne UTC(k), l’état de synchronisation, le cycle de la clé, la fenêtre d’incident et les preuves de validation dans le temps.

Deux documents pour deux fonctions

La RFC 3628 est un texte informatif de 2003, techniquement issu d’une spécification ETSI de son époque. Elle n’est ni une norme Internet actuelle ni une liste de conformité suffisante en 2026. Mais sa distinction centrale demeure d’une netteté rare : la politique dit ce qui doit être respecté ; la déclaration de pratiques de la TSA décrit comment une organisation précise le respecte dans son environnement réel.

La différence n’est pas éditoriale. Une politique peut être écrite sans connaître le bâtiment, le module cryptographique, la source de temps ou l’équipe qui l’appliquera. La déclaration de pratiques appartient toujours au fournisseur. Elle doit relier les exigences abstraites à son organisation, à ses procédures, à ses installations et à ses systèmes.

L’identifiant de politique placé dans le jeton ne transporte pas ce second document. Il n’en donne ni la version applicable, ni la date d’approbation, ni les obligations des sous-traitants, ni les contrôles utilisés. La RFC admettait une revendication de conformité si la TSA fournissait les preuves correspondantes sur demande ou si un tiers indépendant l’avait évaluée. L’identifiant était donc une porte vers le dossier, pas le dossier lui-même.

Ce que le jeton sait vraiment

La RFC 3161 fournit une structure précise. L’empreinte doit correspondre à celle de la requête. Le numéro de série doit être unique pour la TSA, même après une interruption. genTime indique l’instant où la TSA a créé le jeton. Le champ de politique désigne les règles appliquées. Un nonce demandé doit être restitué. La signature et l’identifiant de certificat rattachent l’objet à une clé.

Ce mécanisme apporte une preuve d’existence avant un instant. Il ne prouve pas que le document est vrai, complet ou licite, ni que son auteur supposé l’a créé à cette heure. Il ne prouve pas non plus qu’un service l’a reçu avant une échéance ou qu’une application l’a accepté. L’horodatage porte sur une représentation du datum, pas sur toutes les assertions ultérieures qu’on lui associera.

Même l’ordre temporel reste borné. L’exactitude forme un intervalle autour de genTime. Lorsque le drapeau ordering n’est pas vrai, deux jetons ne peuvent être ordonnés par leur seule heure que si l’écart dépasse la somme de leurs exactitudes. La RFC 5816 modernise le lien au certificat signataire avec ESSCertIDv2 ; elle ne transforme pas l’objet en preuve du fonctionnement de la TSA.

La lettre Z ne montre aucune chaîne métrologique

La RFC 3628 exigeait une heure traçable jusqu’à une valeur réelle diffusée par un laboratoire UTC(k), dans la limite d’exactitude annoncée. Cette exigence ne signifie pas qu’une chaîne de caractères UTC suffit. Elle suppose une relation mesurée entre l’horloge de l’unité d’horodatage et une réalisation locale reconnue.

Le BIPM calcule l’UTC à partir des données de nombreux laboratoires et publie, dans sa Circulaire T mensuelle, les écarts entre l’UTC et les UTC(k). Cette publication établit la traçabilité définitive. UTCr arrive chaque semaine pour aider au pilotage opérationnel. Le BIPM précise qu’UTCr complète l’UTC sans remplacer les résultats définitifs ni la traçabilité de la Circulaire T.

Une signature correcte sur une heure terminée par Z ne révèle donc pas le laboratoire, le chemin de distribution, l’écart observé, l’incertitude, l’âge de la dernière synchronisation ou un passage en maintien libre. La notation appartient au jeton. La traçabilité appartient à un ensemble d’observations et de responsabilités extérieures.

La référence a elle-même évolué. La RFC 3628 citait l’ITU-R TF.460-5, désormais remplacée ; TF.460-6 est en vigueur. L’ETSI EN 319 421 V1.3.1 emploie la version actuelle. Une politique durable doit savoir changer ses dépendances sans prétendre que l’ancien numéro reste éternellement suffisant.

L’arrêt est une preuve positive

Lorsque l’horloge dérive ou saute hors de l’exactitude déclarée et que l’écart est détecté, la RFC 3628 interdit l’émission de nouveaux jetons. La norme ETSI de 2025 conserve cette obligation : protéger l’horloge contre les changements indétectés, détecter la désynchronisation, arrêter l’émission, puis récupérer avant de reprendre.

La disponibilité n’est donc pas toujours le bon indicateur. Un service qui s’arrête au bon moment respecte mieux son autorité qu’un service disponible qui continue de signer une heure incertaine. Il faut observer l’instant de la dernière calibration correcte, le premier soupçon, la détection, l’arrêt effectif, la reprise autorisée et les numéros de série potentiellement touchés.

Le traitement d’une seconde intercalaire suit la même logique. La synchronisation doit être maintenue et l’instant exact du changement enregistré dans la limite annoncée. Constater après coup que l’affichage est revenu à l’heure ne démontre pas ce qui s’est passé pendant la transition.

Une seule clé active est un état d’exploitation

Une TSU est définie comme un ensemble matériel et logiciel géré comme une unité, avec une seule clé de signature d’horodatage active à la fois. Une TSA peut exploiter plusieurs TSU identifiables, chacune avec sa frontière de clé. La norme actuelle conserve cette règle et ajoute le contrôle à deux personnes, le dispositif cryptographique sécurisé, l’usage exclusif de la clé et le refus de signer après son expiration opérationnelle.

Le certificat ne démontre pas tous ces faits. Il indique qu’une clé publique a été certifiée et permet de vérifier la signature. Il ne montre pas qu’aucune deuxième clé n’était active, que la génération et la sauvegarde ont respecté le double contrôle, que la clé privée n’a pas dépassé sa durée d’usage ou que les services qualifiés et non qualifiés ont été correctement séparés.

Cette frontière explique pourquoi les journaux de cycle de vie importent autant que le jeton. La conformité ne réside pas seulement dans la cryptographie choisie ; elle réside aussi dans l’impossibilité organisationnelle de faire signer une autre clé sans laisser de trace.

Un incident doit désigner ses jetons

La RFC 3628 imposait d’informer abonnés et parties utilisatrices d’une compromission, d’une suspicion de compromission ou d’une perte de calibration, d’interrompre l’émission jusqu’au rétablissement et, si possible, d’identifier les jetons susceptibles d’être touchés. L’ETSI EN 319 421 V1.3.1 maintient cette exigence et demande des traces distinctes pour les clés, les certificats, la synchronisation normale, le recalibrage et la perte de synchronisation.

Une déclaration générale comme « incident résolu » ne permet aucun tri. Le dossier utile nomme la TSU, le certificat, la dernière observation saine, la détection, l’arrêt, la récupération et une plage de temps ou de séries. Sans cette frontière, des jetons intacts restent invérifiables du point de vue opérationnel.

Une piste d’audit peut aider à distinguer les jetons authentiques de faux jetons antidatés après compromission. Deux TSA indépendantes peuvent ajouter une seconde observation. L’indépendance doit cependant être démontrée : deux services qui utilisent la même source de temps ou le même module ne fournissent pas nécessairement deux chaînes distinctes.

« Qualifié » n’est pas une auto-certification du jeton

Le règlement européen consolidé accorde aux horodatages électroniques qualifiés une présomption d’exactitude de la date et de l’heure ainsi que d’intégrité des données liées. Le règlement d’exécution (UE) 2025/1929 cite désormais l’ETSI EN 319 421 V1.3.1 et l’EN 319 422 V1.1.1, avec adaptations, comme standards de référence pour la présomption de conformité.

Cette route institutionnelle reste extérieure à l’objet signé. L’ETSI précise que la déclaration de qualification présente dans le jeton n’est qu’une indication de la revendication. La partie utilisatrice doit consulter la liste de confiance appropriée pour établir le statut qualifié. Une extension peut dire « je revendique » ; elle ne peut pas tenir lieu de décision du système de supervision.

Le règlement de 2025 renforce en outre la certification cryptographique, la formation, les scans de vulnérabilité, les tests d’intrusion, HTTPS et la planification de fin de service. Aucun de ces contrôles n’apparaît par magie lors du décodage ASN.1. La présomption juridique repose sur une infrastructure de preuves qu’il faut conserver.

La vérification vieillit

La RFC 3628 avertit qu’un jeton valable aujourd’hui ne le restera pas nécessairement. Pendant la validité du certificat de la TSU, il faut consulter l’état de révocation actuel. Après son expiration, l’autorité de certification peut ne plus publier assez d’informations pour établir qu’aucune compromission n’est survenue. Les algorithmes de hachage et de signature peuvent aussi perdre leur force.

L’annexe C exige alors une connaissance continue : clé non compromise jusqu’à la vérification, absence de collision exploitable et signature toujours hors de portée. À défaut, un horodatage de préservation supplémentaire peut protéger l’objet précédent. Le résultat vert est une observation datée, jamais une propriété éternelle du fichier.

Le paquet minimal comprend ainsi le jeton, son empreinte, les documents de politique et de pratiques applicables, la chaîne de certificats et leurs états, les preuves UTC(k), le cycle de vie de la clé, les avis d’incident, la liste de confiance pertinente, l’évaluation cryptographique et chaque événement de préservation. Réunir ces pièces ne crée pas une autorité centrale nouvelle ; cela empêche simplement une couche d’usurper les autres.

Sources

  1. RFC 3628 — exigences de politique pour les autorités d’horodatage
  2. Texte brut de la RFC 3628
  3. Fiche RFC Editor de la RFC 3628
  4. Dossier Datatracker de la RFC 3628
  5. Recherche d’errata de la RFC 3628
  6. RFC 3161 — protocole d’horodatage
  7. Fiche RFC Editor de la RFC 3161
  8. Dossier Datatracker de la RFC 3161
  9. RFC 3161 avec errata intégrés
  10. RFC 5816 — mise à jour ESSCertIDv2
  11. Fiche RFC Editor de la RFC 5816
  12. Dossier Datatracker de la RFC 5816
  13. ETSI EN 319 421 V1.3.1
  14. ETSI EN 319 422 V1.1.1
  15. Circulaire T du BIPM
  16. Temps universel coordonné au BIPM
  17. UTC rapide du BIPM
  18. Recommandation ITU-R TF.460
  19. Recommandation ITU-R TF.536-2
  20. Règlement (UE) nº 910/2014 consolidé
  21. Règlement d’exécution (UE) 2025/1929
  22. Lu Heng — Running Code Primary
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — On Reality Layers
  25. Lu Heng — On Authority and Belief