Résumé

  • La RFC 3125 demandait qu’un identifiant mondial de politique et le condensat d’une spécification définitive soient liés au calcul de signature, afin que le vérificateur sache quelles règles exactes appliquer.
  • Une signature et un condensat corrects ne suffisaient pas : période, engagement, certificats, révocation, horodatage, attributs, algorithmes et reconnaissance juridique ou contractuelle restaient des tests distincts.

La cryptographie ne contenait pas tout le contrat

Une signature peut vérifier qu’un ensemble d’octets correspond à une clé et à un algorithme. Une transaction exige d’autres réponses. Le certificat était-il acceptable pour cet usage ? La date appartenait-elle à la période autorisée ? Le signataire déclarait-il approuver, recevoir ou seulement produire le document ? Une preuve de révocation ou un horodatage était-il obligatoire ?

Publiée comme RFC expérimentale en septembre 2001, la RFC 3125 regroupait ces décisions sous le nom de politique de signature. Une politique fixait les règles de création et de validation permettant de déterminer une validité dans son propre cadre. Un contexte légal ou contractuel pouvait reconnaître une politique comme répondant à ses besoins. Le texte ne transformait pas cette possibilité en reconnaissance automatique.

Les rôles demeuraient séparés : l’émetteur de politique définissait les exigences ; le signataire s’engageait envers une politique référencée ; le vérificateur l’appliquait ; un arbitre pouvait reprendre le contrôle après coup ; plusieurs prestataires fournissaient certificats, états, temps ou attributs. Partager le même objet ne fusionnait pas leur autorité.

L’OID nommait la politique sans la remplacer

La politique devait être identifiable par un Object Identifier. Une spécification devait exister et posséder une forme définitive à encodage binaire unique. Le signataire fournissait le condensat de cette forme avec un algorithme convenu ; le vérificateur le recalculait.

Cette chaîne évitait qu’un titre vague ou une traduction désigne plusieurs éditions. L’OID identifiait la politique ; le hash rattachait la signature à des octets précis. Dans la forme structurée facultative, ASN.1 et DER offraient un encodage déterministe.

Mais l’OID n’était ni le texte ni un sceau d’approbation. Un hash concordant prouvait que les deux côtés traitaient la même spécification définitive. Il ne prouvait pas que l’émetteur avait compétence pour cette opération, qu’une procédure humaine avait été suivie ou qu’un tribunal reconnaîtrait la règle.

La RFC exigeait donc une forme lisible par l’humain, afin que la politique puisse être évaluée dans son contexte. La forme calculable automatisait l’application ; elle n’automatisait pas la légitimité de l’institution.

Une politique distribuait plusieurs formes de validité

La structure comportait une période de signature, des règles communes et des règles par engagement. La période fixait une date de début et éventuellement de fin pour la création. Un calcul correct réalisé hors période pouvait rester mathématiquement correct tout en échouant à la politique.

Les règles communes couvraient obligations du signataire et du vérificateur, confiance des certificats, des horodatages et des attributs, contraintes algorithmiques et extensions. Les règles d’engagement pouvaient adapter ces familles à une promesse donnée. Approbation, réception ou engagement implicite dans le message ne demandaient pas forcément les mêmes preuves.

La validité devenait donc une proposition complète : valide selon telle version, tel engagement, tels points de confiance, tel instant et tel logiciel. Le mot « valide » privé de ces paramètres détruisait l’information que le standard cherchait à conserver.

Les services de confiance produisaient des pièces limitées

La RFC citait autorités de certification et d’enregistrement, dépôts, autorités d’horodatage, répondeurs d’état et autorités d’attributs. Une politique pouvait choisir des points de confiance, limiter les chemins, exiger des politiques de certificat, des preuves de révocation ou des rôles certifiés.

Chaque service répondait à une question bornée. Un certificat liait une clé à une assertion d’identité. Un état parlait d’un certificat dans un modèle et un temps. Un horodatage attestait l’existence de données avant un instant. Un attribut pouvait documenter un rôle. Aucun ne décidait seul de l’engagement commercial.

Le vérificateur assemblait ces pièces sous la politique. Pour qu’un arbitrage futur soit reproductible, il devait garder la politique, les réponses reçues, les heures, le chemin, le logiciel et la règle choisie, pas seulement un voyant vert.

Les procédures pouvaient échapper au logiciel

Certaines exigences étaient visibles dans CMS : attributs signés ou non signés, références de certificats, certificats inclus. D’autres pouvaient concerner garde de clé, délégation, contrôle interne ou approbation humaine.

Le hash du règlement montre quel règlement était invoqué. Il ne montre pas que chaque geste prescrit s’est produit. La représentation du signataire constituait un engagement, non une télémétrie universelle. Il fallait chercher les preuves procédurales dans d’autres systèmes.

Cette limite interdit de transformer « vérifié sous OID X » en « l’auteur avait pouvoir », « le partenaire a accepté » ou « le contrat a été exécuté ». Autorisation, acceptation, paiement et prestation appartiennent à d’autres étapes.

Les algorithmes rendaient la décision historique

La RFC insistait sur la protection de la clé privée et sur l’affaiblissement des algorithmes avec le temps. Elle recommandait des implémentations modulaires et permettait à la politique de contraindre algorithmes et tailles de clé.

Une vérification tardive devait donc conserver la version de politique applicable, le moment de signature, les horodatages et la règle de migration. Le retrait ultérieur d’un algorithme ne pouvait être interprété sans cette histoire.

La RFC 3126 décrivait des formats de signature à long terme ; la RFC 3161 fournissait l’horodatage. Les RFC 2630, 2634, 2459 et 2560 formaient le contexte CMS, S/MIME, certificat et état de l’époque. Les RFC 5280 et 5652 montrent une lignée ultérieure. Aucune de ces sources n’atteste un déploiement nommé de la RFC 3125.

Une RFC expérimentale n’était pas une statistique d’usage

L’exigence de conformité demandait aux systèmes signataire et vérificateur de traiter la signature selon la politique identifiée. Elle décrivait le comportement d’un participant conforme, non le nombre d’organisations participantes.

L’apport vérifiable de la RFC fut de rendre la politique adressable : OID, forme définitive, encodage unique, hash, règles de confiance et engagements. L’adoption, l’interopérabilité, la reconnaissance et les litiges ont besoin d’archives supplémentaires.

Le reçu complet devrait préserver objet, signature, certificat, OID, octets de politique, hash, période, engagement, chemins, révocation, temps, attributs, contraintes et sortie du vérificateur, puis l’accord externe qui reconnaissait la politique. Le calcul fermait une équation ; la politique disait quelle équation compter.

Sources

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