Horodatage RFC 3161 ou heure serveur : quelle preuve temporelle pour une signature ?
Une date applicative et un jeton d’horodatage ne répondent pas au même besoin. Apprenez à articuler journal UTC, TSA et validation long terme.
Toute procédure de signature enregistre des dates. Mais une ligne « signé à 14:32 UTC » dans une base n’a pas la même portée qu’un jeton émis par une autorité d’horodatage. Confondre les deux crée une promesse probatoire que l’architecture ne peut pas toujours soutenir.
Le protocole RFC 3161 décrit une requête contenant l’empreinte de la donnée et une réponse de la TSA. Cette brique peut contribuer à établir qu’une donnée existait avant un instant donné, notamment pour raisonner sur la validité d’un certificat.
Le rôle de l’horloge applicative
Les événements métier doivent être enregistrés en UTC avec une source synchronisée et une surveillance de dérive. Cette chronologie est indispensable pour comprendre le parcours, détecter les anomalies et corréler e-mails, API et opérations cryptographiques.
Protégez le journal contre la réécriture. Chaînage de hashes, stockage append-only et contrôle d’accès renforcent son intégrité. Mais même bien protégé, il reste produit par l’organisation elle-même : il faut le présenter comme tel.
Ce qu’ajoute une TSA RFC 3161
La requête contient l’identifiant de l’algorithme et l’empreinte, éventuellement une politique et un nonce. La réponse signée relie cette empreinte à une date. Vérifiez le certificat de la TSA, la politique, le statut et l’inclusion de la chaîne nécessaire.
L’utilisation d’un nonce aide à relier réponse et requête. Les erreurs, délais et indisponibilités doivent conduire à un état explicite : ne finalisez pas silencieusement un document annoncé B-T si le jeton n’a pas été obtenu.
Organiser la validation dans le temps
Conservez le jeton, la réponse complète, le certificat, la politique et l’empreinte concernée. Intégrez ces éléments au dossier de preuve et au format PAdES lorsque la politique le prévoit.
Testez la validation après expiration d’un certificat dans un environnement contrôlé. La stratégie long terme doit prévoir révocation, évolution des algorithmes et renouvellement d’horodatages, pas seulement l’appel initial à la TSA.
Grille de décision
| Élément | Heure serveur | Jeton RFC 3161 |
|---|---|---|
| Émetteur | Application | Autorité d’horodatage |
| Objet | Événement métier | Empreinte d’une donnée |
| Vérification | Logs et synchronisation | Signature et certificat TSA |
| Dépendance | Infrastructure interne | Service, politique et chaîne de confiance |
Plan d’action
- Synchroniser et surveiller les horloges
- Choisir une TSA et une politique explicites
- Utiliser un nonce lorsque pertinent
- Bloquer ou dégrader explicitement en cas d’échec
- Archiver jetons et certificats
- Tester la validation longue durée
Questions fréquentes
La TSA reçoit-elle le PDF ?
Le protocole travaille normalement sur une empreinte ; le document n’a pas besoin d’être transmis à la TSA.
Un timestamp de base de données est-il inutile ?
Non. Il est essentiel à la chronologie, mais il ne doit pas être présenté comme un jeton tiers ou qualifié.
Tous les jetons RFC 3161 sont-ils qualifiés ?
Non. La qualification dépend du prestataire et du service, à vérifier dans les sources officielles.
Sources officielles et techniques
Important
Ce contenu fournit une information générale et ne remplace pas un avis juridique ou un audit de conformité. Le niveau de signature adapté dépend du contexte, de l’identification, de l’authentification et des preuves effectivement produites.