Résumé
- RFC 9921 n’ajoute pas « une date » à COSE : il définit CTT, qui horodate le champ de signature, et TTC, qui horodate d’abord les octets de charge utile.
- Un jeton TTC protégé par une signature ultérieure ne permet pas de conclure que cette signature existait avant la révocation de son certificat.
Le dossier d’archivage paraissait irréprochable. Le jeton de l’autorité d’horodatage portait une date antérieure à la révocation. La signature COSE validait. Le jeton figurait même dans un en-tête protégé : une lecture rapide y voyait la preuve que l’auteur avait signé à temps.
Cette lecture confondait l’ordre des opérations avec leur présentation finale.
Un signataire peut faire horodater lundi le hachage d’une charge utile, attendre la révocation de son certificat, puis signer mercredi l’ensemble formé de cette charge utile et du jeton de lundi. L’objet final est cohérent. Le jeton est bien protégé par la signature de mercredi. Mais le jeton n’a jamais couvert les octets de cette signature. Il atteste de l’existence antérieure de la charge utile, non de l’existence antérieure de l’acte de signature.
RFC 9921 formalise ce point pour COSE_Sign et COSE_Sign1 en intégrant les TimeStampTokens de RFC 3161. Sa mise en garde de sécurité est explicite : interpréter un horodatage de charge utile comme une preuve de création de signature peut conduire à accepter une signature faite après révocation. Ce n’est donc pas une nuance de vocabulaire. C’est une frontière d’admission.
Deux constructions, deux questions recevables
Dans le mode COSE, Then Timestamp (CTT), l’émetteur produit d’abord la signature COSE. Il calcule ensuite le MessageImprint sur le champ signature encodé en CBOR d’un COSE_Sign1, ou sur le champ signatures encodé en CBOR d’un COSE_Sign. L’autorité d’horodatage signe ce hachage, et le jeton revient dans le paramètre d’en-tête non protégé 3161-ctt.
La portée est ici très précise : le TSA a reçu une représentation des octets de signature, selon le périmètre d’encodage fixé par le RFC. Après vérification de la signature COSE, du jeton et de la chaîne de confiance pertinente, le valideur peut conclure que la signature était déjà présente à l’instant du TSA. C’est pourquoi RFC 9921 destine CTT aux signatures de longue durée, notamment lorsque l’expiration ou la révocation ultérieure d’un certificat ne doit pas effacer une preuve historique correctement constituée.
Dans le mode Timestamp, Then COSE (TTC), l’ordre est inversé. Le demandeur fait d’abord horodater le hachage des seuls octets de charge utile. Le MessageImprint n’inclut ni l’enveloppe CBOR bstr, ni une signature encore inexistante. Le jeton est placé dans le paramètre protégé 3161-ttc; la signature COSE est alors calculée sur l’en-tête protégé et la charge utile.
TTC produit un objet utile : la charge utile et son horodatage sont scellés ensemble par la signature COSE ultérieure. Le RFC l’emploie pour une logique de transparence et de notarisation, où le jeton doit rester dans l’énoncé signé avant l’inscription des parties signées dans un journal append-only. Mais la protection de l’en-tête n’invente pas une signature antérieure. Elle établit seulement qu’un signataire ultérieur a couvert un jeton relatif à cette charge utile.
Le bon verbe de CTT est « la signature existait déjà ». Le bon verbe de TTC est « la charge utile existait déjà ». Les remplacer l’un par l’autre, c’est déplacer la date d’un fait à un autre fait.
Protéger le transport de la preuve CTT
Le caractère non protégé de 3161-ctt n’est pas une omission accidentelle. Le jeton n’existait pas lorsque la signature COSE a été produite; cette signature ne pouvait pas le couvrir rétrospectivement. RFC 9921 identifie donc un risque pratique : le jeton CTT peut être retiré ou remplacé. Le message COSE signé doit être protégé pour le transport et la conservation afin de préserver l’association entre la signature et le jeton.
Cette exigence ne diminue pas la valeur de CTT; elle précise son environnement. Un coffre, une couche de transport ou un paquetage d’archivage doit empêcher la séparation silencieuse des éléments. Le dossier de preuve doit conserver le hachage de l’artefact, le mode CTT, les octets qui ont servi à l’empreinte, le certificat et la politique du TSA, ainsi que le contrôle de chaîne effectué. Une interface qui affiche « horodatage vérifié » sans pouvoir établir que le jeton était associé au message conservé ne résume plus le fait utile.
De même, le caractère protégé de 3161-ttc est une garantie d’intégrité du paquet postérieur, non une machine à remonter le temps. Il empêche la modification du jeton sans casser la signature COSE. Il ne permet pas de transformer une preuve d’existence de données en preuve de validité temporelle de la signature.
L’heure est une politique vérifiée, pas un champ lisible
RFC 3161 rappelle qu’un TSA horodate une représentation hachée sans en examiner la signification. Le client vérifie donc le statut de réponse, l’identité et le certificat du TSA, l’empreinte demandée, l’algorithme, la fraîcheur de la réponse ou le nonce, le statut du certificat du TSA et l’acceptabilité de la politique d’horodatage. genTime désigne le moment où le TSA a produit son jeton; la précision, l’exactitude annoncée, la latence et la politique bornent l’interprétation.
RFC 9921 ajoute le contrôle que les systèmes omettent le plus facilement : recalculer l’empreinte sur les octets exacts exigés par le mode choisi. Un jeton CMS voisin d’un objet ne suffit jamais. Pour CTT, l’empreinte doit correspondre au champ de signature; pour TTC, aux seuls octets de charge utile. La décision doit ensuite porter le sens correspondant, et non celui qui arrange le dossier.
La doctrine de Heng Lu aide à tenir cette discipline. Du code qui affiche une date n’a encore ni appliqué une politique de révocation ni autorisé une opération. La réalité pertinente est la chaîne exécutée : classification CTT/TTC, recalcul d’empreinte, validation TSA, preuve de statut, politique versionnée, décision responsable et effet observé. Un objet analysé, une preuve cryptographique et une autorisation sont trois couches, pas trois noms pour le même succès.
Sources
- https://www.rfc-editor.org/rfc/rfc9921.html
- https://www.rfc-editor.org/info/rfc9921/
- https://www.rfc-editor.org/rfc/rfc3161.html
- https://www.rfc-editor.org/rfc/rfc9052.html
- https://www.rfc-editor.org/rfc/rfc5652.html
- https://www.rfc-editor.org/rfc/rfc5280.html
- https://www.iana.org/assignments/cose/cose.xhtml#header-parameters
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

