La demande contient l’empreinte
Le client calcule le SHA-256 du fichier et n’envoie à l’autorité que cette empreinte, avec un nombre aléatoire (nonce) pour reconnaître la réponse. Le fichier ne voyage pas.
Horodatage RFC 3161 · guide technique
Qu’est-ce qu’un horodatage RFC 3161 et comment le vérifier
Une autorité d’horodatage (TSA) signe l’empreinte d’un fichier avec une date et une heure. Voici ce que contient cette réponse, comment la vérifier avec OpenSSL ou dans le navigateur, et comment l’obtenir par API.
Vous cherchiez à convertir un timestamp Unix en date ? C’est autre chose : ici, on date un fichier.
Vérifier un .tsr
Ouvre le validateur : vous ajoutez le fichier et son horodatage, et l’empreinte est calculée dans votre navigateur.
Les émettre depuis votre système : l’API → Seule l’empreinte voyage La demande contient un SHA-256 : l’autorité ne voit jamais le fichier.
Standard ouvert La RFC 3161, le protocole de l’IETF qu’utilisent les autorités d’horodatage depuis 2001.
Vérifiable sans dépendre de personne Avec OpenSSL ou n’importe quel validateur, sans dépendre de celui qui l’a émis.
Ce que c’est
Une demande, une autorité et un jeton.
La RFC 3161 est le standard de l’horodatage, et ce qu’elle fait est plus simple qu’il n’y paraît.
La TSA signe l’heure
L’autorité d’horodatage lie cette empreinte à une date et une heure de son horloge, et signe le tout avec un certificat réservé à l’horodatage.
La réponse est le jeton
Elle renvoie un .tsr : le statut de la demande et, si elle est accordée, le jeton signé. Avec le fichier et le jeton, n’importe qui peut le vérifier ensuite.
Dans le .tsr
Ce que contient un .tsr.
Un .tsr est une structure ASN.1 encodée en DER. Voici les champs qui comptent, sous le nom que leur donne le standard.
status- Le statut de la demande : accordée ou rejetée, entre autres. Il précède le jeton, et c’est ce qui fait échouer les validateurs qui n’attendent qu’un .tst.
messageImprint- L’algorithme (SHA-256) et l’empreinte du fichier. C’est la donnée que l’on compare avec le fichier que vous avez.
genTime- La date et l’heure que signe l’autorité, en UTC. C’est l’heure de l’horodatage.
serialNumber- Le numéro que l’autorité attribue à ce jeton, unique parmi tous ceux qu’elle émet.
policy- L’identifiant (OID) de la politique d’horodatage sous laquelle il a été émis.
nonce- Le nombre aléatoire de la demande, renvoyé tel quel : il montre que cette réponse correspond à cette demande.
SignedData- L’enveloppe CMS : la signature de l’autorité sur tout ce qui précède et, si la demande l’exigeait, son certificat. Sellat le demande toujours.
Un .tst n’est que le jeton, sans le statut. Les deux portent la même preuve : c’est l’enveloppe qui change, pas ce qu’elle prouve.
Qualifié ou non
Horodatage qualifié ou non qualifié : le même jeton, deux niveaux juridiques.
Techniquement, un jeton RFC 3161 est le même quel que soit son émetteur : l’empreinte, l’heure et la signature se vérifient de la même manière. Ce qui change, c’est qui le signe.
Le règlement (UE) 910/2014 (eIDAS) appelle qualifié l’horodatage qui remplit les exigences de son article 42 : il lie la date et l’heure aux données de manière à exclure raisonnablement toute modification indétectable des données, il est fondé sur une horloge exacte liée au temps universel coordonné et il est signé ou cacheté par un prestataire de services de confiance qualifié, inscrit comme tel sur la liste de confiance d’un État membre.
Aucun horodatage électronique ne peut se voir refuser l’effet juridique ni la recevabilité comme preuve au seul motif qu’il se présente sous forme électronique ou qu’il n’est pas qualifié (art. 41.1). L’horodatage qualifié bénéficie en outre d’une présomption d’exactitude de la date et de l’heure et d’intégrité des données (art. 41.2).
Comment obtenir un horodatage qualifié →Vérifier avec OpenSSL
Trois commandes, sur votre ordinateur.
Il vous faut le fichier, le .tsr et le certificat de l’autorité qui l’a signé (dans un dossier Sellat, autoridad-sellado.pem). Rien ne quitte votre machine.
- 01
Lisez ce que dit l’horodatage
openssl ts -reply -in horodatage.tsr -textAffiche le statut et le contenu du jeton : la politique, l’empreinte (« Message data »), le numéro de série, l’heure et le nonce.
- 02
Calculez l’empreinte du fichier
openssl dgst -sha256 fichierElle doit correspondre au « Message data » de l’étape précédente, qu’OpenSSL affiche en blocs hexadécimaux. Si un seul octet du fichier change, elle ne correspond plus.
- 03
Vérifiez signature et empreinte en même temps
openssl ts -verify -in horodatage.tsr -data fichier -CAfile autoridad-sellado.pem -partial_chainSi tout concorde, la réponse est « Verification: OK ».
Le certificat de l’autorité est une feuille, pas une AC : sans -partial_chain, OpenSSL cherche son émetteur et échoue. C’est la raison la plus fréquente pour laquelle un validateur rejette un horodatage correct. Si vous avez un .tst, ajoutez -token_in aux commandes.
Vérifier dans le navigateur
Le validateur d’horodatage accepte le .tsr ou le .tst avec le fichier. L’empreinte est calculée sur votre appareil, et seuls l’empreinte et l’horodatage sont envoyés. Il vous dit séparément si la structure, l’empreinte, la signature, le certificat signataire et la liste de confiance de l’UE sont conformes.
Vérifier un .tsrPar API
Comment l’obtenir par l’API de Sellat.
Sellat n’est pas une autorité d’horodatage : le jeton RFC 3161 que vous obtenez par Sellat est l’horodatage qualifié émis par la FNMT-RCM. Sellat le demande sur l’empreinte que vous envoyez, le vérifie contre la liste de confiance de l’UE et le conserve dans votre preuve.
- 01
Calculez l’empreinte
Le SHA-256 du fichier, sur votre système. C’est la seule chose envoyée.
- 02
Créez la preuve avec l’horodatage
POST /api/v2/proofs avec "qualified": true, ou POST /api/v2/proofs/{id}/qualified sur une preuve existante. Avec une Idempotency-Key, une nouvelle tentative ne compte jamais deux fois et n’horodate jamais deux fois.
- 03
Téléchargez le .tsr
GET /api/v2/proofs/{id}/qualified.tsr renvoie la réponse de l’autorité telle quelle, en DER, prête pour OpenSSL.
curl https://sellat.app/api/v2/proofs \
-H "Authorization: Bearer $SELLAT_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"hash":"<sha256 du fichier>","qualified":true}'Chaque horodatage est décompté de ceux de votre compte : celui de bienvenue ou l’un de vos packs. S’il n’en reste aucun, l’API répond 402 avant de créer quoi que ce soit.
Portée
Ce que cela prouve, et ce que cela ne prouve pas.
Ce que cela prouve
Un jeton RFC 3161 valide prouve que cette empreinte, et donc ce fichier exact, existait au plus tard à l’heure signée par l’autorité, et qu’il n’a pas changé depuis.
Ce que cela ne prouve pas
Il fixe depuis quand le fichier existe, pas depuis quand existe ce que montre son contenu. Il ne prouve ni la paternité, ni la propriété, ni la véracité ; et l’heure vaut ce que vaut l’autorité qui la signe.
Questions fréquentes
Avant que vous ne le demandiez.
Horodatage, timestamp, horodatage électronique : est-ce la même chose ?
Oui : c’est une même notion sous plusieurs noms. En anglais timestamp, en français horodatage, et dans le règlement européen « horodatage électronique ». Ce qui les distingue n’est pas le nom, mais le fait d’être qualifiés ou non.
Quelle différence entre un .tsr et un .tst ?
Le .tsr est la réponse complète de l’autorité (TimeStampResp) : le statut de la demande plus le jeton. Le .tst n’est que le jeton (TimeStampToken, un SignedData CMS). Beaucoup de validateurs n’acceptent que le .tst ; avec OpenSSL, un .tst se lit en ajoutant -token_in.
Pourquoi OpenSSL dit-il qu’il ne trouve pas l’émetteur du certificat ?
Parce que le certificat de l’autorité que vous lui passez avec -CAfile est une feuille, pas une AC, et qu’OpenSSL essaie de construire la chaîne jusqu’à une racine. Avec -partial_chain, il accepte la feuille comme point de confiance et vérifie l’horodatage.
Une TSA gratuite me suffit-elle ?
Pour prouver techniquement qu’un fichier existait, oui : un jeton RFC 3161 reste un jeton RFC 3161. Ce que vous n’obtenez pas, c’est la présomption légale de l’article 41.2, qui n’accompagne qu’un horodatage émis par un prestataire qualifié de la liste de confiance de l’UE.
Quelle heure fait foi ?
Dans l’horodatage, celle du champ genTime, que l’autorité signe en UTC. Une preuve Sellat contient en plus l’heure de l’ancrage public : ce sont des heures différentes, de couches différentes, toujours affichées séparément.
Puis-je vérifier un .tsr qui ne vient pas de Sellat ?
Oui. OpenSSL et le validateur de ce site acceptent le .tsr ou le .tst de n’importe quelle autorité. Le validateur ne le dit qualifié que si l’autorité figure comme service qualifié sur la liste de confiance de l’UE.
Puis-je l’automatiser ?
Oui. L’API accepte des empreintes par HTTP et renvoie une preuve pour chacune, sans envoyer les originaux ; il existe aussi un outil en ligne de commande open source. C’est ce que nous utilisons nous-mêmes pour horodater des logs toutes les heures.
Et un horodatage blockchain, comme OpenTimestamps ?
C’est une autre façon de dater une empreinte, sans autorité : l’empreinte, agrégée avec d’autres dans un arbre de Merkle, est ancrée dans une chaîne publique comme Bitcoin, et l’heure est celle du bloc. Ce n’est pas un jeton RFC 3161 et cela ne peut pas être qualifié, mais cela ne dépend de la survie de personne. Sellat ancre ainsi toutes ses preuves ; la page de la preuve d’existence l’explique.
Vous avez un .tsr sous la main ?
Vérifiez-le dans le navigateur avec son fichier. Si vous voulez les émettre depuis votre propre système, commencez par l’API.
Ouvrir le validateur Les émettre depuis votre système : l’API →