Résumé

  • La validité cryptographique d’une réponse Roughtime atteste une signature, une requête et un intervalle ; elle n’atteste pas que l’heure annoncée est vraie.
  • Une chaîne incohérente démontre qu’au moins un serveur a fourni une heure fausse. L’attribution, l’acceptation du rapport et la révocation appartiennent à d’autres décisions.

Le dossier est fermé sur un point : trois réponses signées, reçues dans un ordre cryptographiquement lié, ne peuvent pas toutes respecter cet ordre. Pourtant, le siège du prévenu reste vide. La contradiction est certaine ; son auteur ne l’est pas.

C’est la frontière utile de la révision 19 de Roughtime. Le texte est un Internet-Draft actif du groupe NTP, destiné au statut Expérimental et en traitement chez le RFC Editor. Ce n’est pas encore un RFC. La comparaison avec la révision 18 montre surtout des retouches éditoriales : il serait faux de présenter l’attribution comme une nouveauté de cette version.

Une signature protège une déclaration

Le client envoie un nonce. Le serveur lie la requête à une feuille d’arbre de Merkle, puis signe une réponse contenant une heure médiane MIDP, un rayon d’incertitude RADI et la racine de l’arbre. Une clé Ed25519 temporaire signe la réponse ; la clé de long terme signe la délégation et ses bornes MINT et MAXT.

Le client vérifie ces deux signatures, l’inclusion de sa requête et la présence du point médian dans la période de délégation. Une réponse qui réussit ces contrôles est valide. Le projet précise aussitôt qu’elle n’est pas pour autant correcte : elle prouve la garantie signée du serveur sur un intervalle, non la vérité physique de son horloge.

Cette nuance interdit un raccourci courant. Une petite valeur de RADI est une affirmation plus précise, pas une vérité créée par l’algorithme. Le certificat répond à « qui a signé quoi, et dans quelle fenêtre ? ». Il ne répond pas seul à « quelle heure était-il réellement ? ».

La chaîne prouve le conflit

Le mode multi-serveurs exige une liste configurée et au moins trois serveurs opérationnels exploités par des parties différentes. Le client les interroge séquentiellement, deux fois dans le même ordre. Après le premier nonce aléatoire, chaque requête dépend de la réponse précédente et d’un nouvel aléa. Le temps déclaré plus tard ne peut donc pas se détacher silencieusement de l’histoire qui le précède.

Si les signatures sont valides mais que deux intervalles violent l’ordre causal, il y a « malfeasance » au sens du projet. Le rapport conserve clés attendues, aléas, requêtes et réponses dans l’ordre de réception. Il démontre qu’au moins un serveur a communiqué une heure fausse.

« Au moins un » n’est pas un nom. Une minorité isolée peut être fautive ; elle peut aussi être honnête face à deux serveurs partageant la même mauvaise source. La diversité des exploitants, des sources de temps et du contrôle de la liste n’est donc pas un décor organisationnel. Elle conditionne ce que le conflit permet raisonnablement d’inférer.

Le protocole ne se nomme pas juge

Le projet fournit des formats communs pour la liste et le rapport. Il ne définit ni l’autorité qui inscrit un serveur, ni la règle d’acceptation d’un dossier, ni l’enquête qui attribue la faute, ni le recours après révocation. Un forum d’observateurs humains n’est cité que comme possibilité simple. Le même texte qualifie pourtant la maintenance de la liste et l’adjudication d’essentielles à la sécurité.

Cette absence doit rester visible. Une organisation devrait conserver séparément la réponse brute, la validité des signatures, la paire contradictoire, la version de liste, l’état d’examen, la décision d’attribution, la révocation et la propagation vers les clients. Envoyé, accepté, attribué, révoqué et corrigé décrivent cinq moments différents.

Même l’expiration d’une clé déléguée ne clôt pas tout. Si sa clé privée est compromise plus tard, elle peut signer de fausses heures antidatées dans son ancienne fenêtre. La rotation limite l’usage futur ; elle n’efface pas la question historique.

Roughtime peut amorcer une validation de certificat ou borner des observations NTP/PTP. Il ne devient ni horodatage légal, ni séquenceur universel de transactions, ni preuve d’intégrité de l’appareil, ni reçu d’exécution réelle.