Résumé

  • ES-T fixait l’existence de la signature dans le temps ; ES-C référençait certificats et éléments de révocation ; ES-X conservait ou protégeait ces éléments ; ES-A permettait de renouveler l’enveloppe avant l’affaiblissement des protections antérieures.
  • La durée ne venait pas d’un format magique. Elle exigeait les octets exacts, les valeurs de validation et des renouvellements effectués pendant que l’ancienne chaîne restait encore défendable.

Les bits survivaient mieux que leur contexte

Copier une signature numérique est facile. Reproduire, vingt ans plus tard, la décision qui l’avait déclarée valide l’est beaucoup moins. Le certificat du signataire expire, l’autorité ne publie plus les anciennes listes, le service de statut disparaît, le certificat de l’autorité d’horodatage arrive à échéance, ou un algorithme perd sa crédibilité.

Publiée comme document informatif en septembre 2001, la RFC 3126 plaça ce décalage au centre. Elle prolongeait la signature régie par une politique de la RFC 3125 avec CMS, ESS, certificats X.509, révocation et horodatage. L’objet à préserver n’était pas seulement la valeur de signature, mais le monde probatoire qui permettait de la relire.

ES-T donnait une date étroite, pas un verdict large

La forme ES contenait la signature de base. ES-T ajoutait un horodatage sur cette signature. Si le signataire ne le fournissait pas, le vérificateur devait le créer à la première réception ou conserver un relevé temporel sécurisé proche de la première vérification.

La RFC 3161 borne cette affirmation : une autorité d’horodatage signe l’empreinte d’une donnée et atteste que cette donnée existait à un moment. Elle n’a pas besoin de lire le document. L’horodatage n’établit donc ni la vérité du texte, ni le pouvoir commercial du signataire, ni l’exécution du contrat.

Cette borne était néanmoins précieuse. Face à une compromission ultérieure de clé, un jeton antérieur pouvait montrer que l’empreinte existait avant l’incident. Mais le jeton possédait lui-même une clé, un certificat, une politique et une durée. La dépendance changeait de place ; elle ne disparaissait pas.

ES-C enregistrait la recette de validation

ES-C se construisait sur ES-T et ajoutait les références au chemin de certification et aux informations de révocation utilisées. Un futur vérificateur pouvait identifier quels certificats, listes ou réponses de statut avaient soutenu la décision initiale.

Cette forme n’était pas toujours disponible au moment de signer. Il fallait parfois attendre que les informations de révocation soient complètes ou qu’une suspension temporaire soit résolue. La preuve de long terme naissait donc par étapes.

Une référence n’était toutefois pas la valeur. Un identifiant ou une adresse de dépôt n’empêchait pas ce dépôt de disparaître. La RFC 3126 réservait à X-Long l’inclusion des certificats et données de révocation eux-mêmes. C’était la différence entre le catalogue d’une bibliothèque et le livre conservé.

La réponse OCSP restait elle aussi limitée. La RFC 2560 distinguait bon, révoqué et inconnu, avec des temps associés. « Bon » répondait à une demande de statut ; il ne certifiait pas toutes les conditions de la chaîne, l’autorité du signataire ou le résultat de l’opération.

ES-X datait les preuves de validation

La famille ES-X traitait deux risques. X-Long conservait les valeurs auxquelles ES-C faisait référence. X-Time-Stamp protégeait ces éléments contre une compromission ultérieure d’une autorité : le type 1 horodatait ES-C en entier, le type 2 les références de certificats et de révocation. Les deux approches pouvaient être combinées.

L’ordre temporel importait. Des certificats produits après la compromission d’une autorité ne racontaient pas la même histoire que des éléments déjà enfermés dans une empreinte datée. ES-X pouvait préserver cette antériorité, sous réserve de la politique applicable et de la fiabilité de l’autorité d’horodatage.

La sophistication ne réparait pas une mauvaise capture. Si le contenu signé avait été perdu, si le mauvais chemin avait été retenu ou si l’horodatage intervenait trop tard, la couche supplémentaire ne faisait que conserver plus exactement l’erreur.

ES-A imposait un calendrier au gardien

ES-A répondait au vieillissement de la protection elle-même. Avant que clés, algorithmes ou certificats d’horodatage ne deviennent faibles, l’ensemble — données signées, ES-C et éléments ES-X — devait recevoir un nouvel horodatage, si possible avec un algorithme plus robuste ou une clé plus longue. Le renouvellement pouvait se répéter.

L’empreinte d’archive couvrait le contenu, les attributs signés, la signature, le premier horodatage, les références, les valeurs conservées, les protections ES-X et tous les horodatages d’archive précédents. La chaîne constituait une forme de garde cryptographique.

Elle n’était pas immortelle. Le gardien devait renouveler tant que la preuve antérieure restait vérifiable. Après la perte des valeurs, la rupture d’un hash ou une compromission sans borne temporelle fiable, un nouveau jeton ne recréait pas le passé. La RFC 4998 systématisa plus tard cette distinction entre renouveler un horodatage et recalculer la preuve avec un nouvel algorithme de hachage.

L’octet exact faisait partie de l’histoire

La RFC 3126 demandait que l’OCTET STRING signé reste identique à chaque vérification. Une migration d’archive pouvait donc casser la preuve sans modifier l’apparence : normalisation des fins de ligne, conversion d’encodage, perte d’un contenu détaché ou réexportation suffisaient.

Le véritable objet durable réunissait octets signés, signature, attributs, politique, chemin de certificats, statut daté, jetons temporels, valeurs conservées et renouvellements successifs. Garder un document rendu avec un simple indicateur « valide » supprimait la possibilité de rejouer la décision.

La RFC 5126 remplaça plus tard la RFC 3126 en conservant les familles CAdES-T, CAdES-C, CAdES-X et CAdES-A. Cette continuité atteste l’utilité conceptuelle de l’échelle, pas le déploiement d’une implémentation précise en 2001.

Une signature durable restait une institution en mouvement

Le signataire créait l’acte initial. Le vérificateur capturait le premier temps et les données complètes. Autorités de certification et services de statut fournissaient des preuves bornées. L’autorité d’horodatage datait une empreinte. Le dépositaire conservait les octets et renouvelait la chaîne. Un arbitre pouvait ensuite appliquer la politique et l’instrument juridique ou contractuel extérieur.

La leçon historique n’est donc pas que l’horodatage rend une signature éternelle. La RFC 3126 transforma la durée en discipline opérationnelle : enregistrer ce que savait le premier vérificateur, conserver ce que les services distants pourraient oublier, protéger ces éléments contre une compromission future et renouveler avant la rupture des hypothèses.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3126.txt
  2. https://www.rfc-editor.org/info/rfc3126
  3. https://datatracker.ietf.org/doc/rfc3126/
  4. https://www.rfc-editor.org/rfc/rfc3125.txt
  5. https://www.rfc-editor.org/rfc/rfc3161.txt
  6. https://www.rfc-editor.org/rfc/rfc2630.txt
  7. https://www.rfc-editor.org/rfc/rfc2634.txt
  8. https://www.rfc-editor.org/rfc/rfc2459.txt
  9. https://www.rfc-editor.org/rfc/rfc2560.txt
  10. https://www.rfc-editor.org/rfc/rfc4998.txt
  11. https://www.rfc-editor.org/rfc/rfc5126.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt