# 09 · Horodatage et conservation : niveaux B-T, B-LT, B-LTA > Section autonome du guide [eIDAS 2, échange par échange](https://signature.codethelaw.eu/). En production RFC 3161, RFC 6960 et EN 319 142-1 ; algorithmes pour la conservation longue selon TS 119 312 V2.1.1, qui recommande désormais des horodatages post-quantiques (SLH-DSA, XMSS, LMS) pour l'archivage de plus de vingt ans. Une signature B-B ne dit rien de la date à laquelle elle existait ni du statut du certificat à ce moment. Chaque niveau ajoute une preuve que la validation future pourra utiliser, même quand l'AC aura disparu ou que l'algorithme sera affaibli. ## 9.1 B-T : demander un jeton d'horodatage sur la signature Application de signature → Autorité d'horodatage · TimeStampReq ### Entrée Requête RFC 3161 (HTTP, application/timestamp-query). **ASN.1 · RFC 3161** ```text TimeStampReq { version 1, messageImprint { hashAlgorithm 2.16.840.1.101.3.4.2.1, -- sha256 hashedMessage }, nonce 0x5F2B…, certReq TRUE } ``` ### Traitement 1. On horodate la valeur de signature : cela prouve que la signature existait à cette date. 2. certReq demande l'inclusion du certificat de l'unité d'horodatage dans la réponse. ### Sortie Réponse (application/timestamp-reply). **ASN.1 · RFC 3161** ```text TimeStampResp { status { status granted (0) }, timeStampToken ContentInfo signedData { eContentType 1.2.840.113549.1.9.16.1.4 -- id-ct-TSTInfo TSTInfo { version 1, policy , messageImprint { sha256, }, serialNumber 2318849, genTime 20261003081507Z, accuracy { seconds 1 }, nonce 0x5F2B… } -- signé par l'unité d'horodatage du prestataire qualifié } } ``` **NOTE 1.** Emplacement : SignerInfo.unsignedAttrs, attribut signature-time-stamp (1.2.840.113549.1.9.16.2.14). La signature ne change pas : l'horodatage s'y attache après coup. **Suite :** Le jeton est ajouté comme attribut non signé de la signature. ## 9.2 B-LT : collecter la preuve de non-révocation Application de signature → Répondeur OCSP · OCSP ### Entrée Requête RFC 6960. **OCSP · RFC 6960** ```text OCSPRequest { tbsRequest { requestList { Request { reqCert CertID { hashAlgorithm 1.3.14.3.2.26 ou 2.16.840.1.101.3.4.2.1, issuerNameHash , issuerKeyHash , serialNumber } } } requestExtensions { id-pkix-ocsp-nonce <…> } } } ``` ### Traitement 1. Le répondeur de l'AC renvoie le statut du certificat, signé par sa propre clé. 2. On collecte aussi les certificats de la chaîne et, si besoin, les CRL. ### Sortie Réponse (extrait). **OCSP · RFC 6960** ```text BasicOCSPResponse { tbsResponseData { responderID byKey <…>, producedAt 20261003081509Z, responses { SingleResponse { certID , certStatus good, thisUpdate 20261003080000Z, nextUpdate 20261004080000Z } } } signatureAlgorithm ecdsa-with-SHA256, signature <…>, certs { } } ``` **Suite :** Ces éléments sont rangés dans le PDF, dans le dictionnaire DSS. ## 9.3 B-LT : ranger les preuves dans le PDF Application de signature → Application de signature · DSS ### Entrée Certificats, réponses OCSP, CRL. **TEXTE** ```text chaîne de certificats du signataire et de l'horodatage, réponse OCSP ``` ### Traitement 1. Nouvelle mise à jour incrémentale : le catalogue du PDF reçoit un dictionnaire /DSS. 2. La signature existante n'est pas touchée. ### Sortie Extrait PDF. **PDF · PAdES** ```text 1 0 obj << /Type /Catalog /Pages 2 0 R /AcroForm 5 0 R /DSS 30 0 R >> endobj 30 0 obj << /Certs [31 0 R 32 0 R 33 0 R] % flux DER des certificats /OCSPs [34 0 R] % flux DER des réponses OCSP /CRLs [] >> endobj ``` **Suite :** La signature est validable sans contacter l'AC. Reste à la protéger contre l'affaiblissement futur des algorithmes. ## 9.4 B-LTA : horodater l'ensemble du document Application de signature → Autorité d'horodatage · DocTimeStamp ### Entrée PDF complet avec DSS. **TEXTE** ```text toutes les révisions du fichier, y compris /DSS ``` ### Traitement 1. Nouvelle mise à jour incrémentale avec une signature de type horodatage de document : le condensat couvre tout le fichier. 2. L'opération est renouvelée avant que les algorithmes ou les clés utilisés ne deviennent faibles : c'est la maintenance des signatures (TS 119 312, annexe B). ### Sortie Extrait PDF. **PDF · PAdES** ```text 40 0 obj << /Type /DocTimeStamp /Filter /Adobe.PPKLite /SubFilter /ETSI.RFC3161 /ByteRange [0 25110 41496 412] /Contents <3082…> % TimeStampToken RFC 3161, sans attribut signé PAdES >> endobj ``` **NOTE 2.** TS 119 312 V2.1.1 : SHA-256 jugé insuffisant pour l'archivage de plus de vingt ans (marge classique de 128 bits) ; recommandation de SHA-384 ou plus et d'algorithmes post-quantiques pour les unités d'horodatage. **Suite :** Le document peut être revalidé dans des décennies, tant que la chaîne de ré-horodatages n'est pas interrompue. ## Sources - [RFC 3161, Time-Stamp Protocol](https://www.rfc-editor.org/info/rfc3161) - [RFC 6960, OCSP](https://www.rfc-editor.org/info/rfc6960) - [ETSI TS 119 312 V2.1.1, annexe B et clause 5.2.2](https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf)