Résumé

  • RFC 3029 permettait à un service de validation de s’exécuter correctement et de produire un certificat authentique dont le résultat était pourtant « invalide ».
  • Le DVC liait empreinte, requête, temps, numéro de série, politique, résultat collectif et détails élémentaires ; l’application devait encore vérifier la réponse et décider de sa portée.

Le vocabulaire de la certification pousse à confondre contenant et conclusion. Lorsqu’un objet est signé par une autorité de confiance, l’interface a tendance à traduire la signature en approbation. Le Data Validation Certificate de RFC 3029 suivait une logique différente. Il certifiait que le serveur avait rendu un résultat sous certaines conditions, y compris lorsque ce résultat constatait l’invalidité de l’objet soumis.

Le texte le dit sans détour : DVCSCertInfo résulte d’une exécution réussie du service, mais cette réussite ne signifie pas que la validation elle-même a réussi. Trois événements doivent donc être conservés séparément. La requête a pu être comprise et traitée. La réponse a pu être authentifiée comme venant du DVCS. Le document, le certificat ou la revendication a pu échouer à la politique choisie.

Quatre services ne disaient pas la même chose

Le service cpd certifiait la possession de données effectivement présentées au serveur. Le service ccpd ne recevait qu’une empreinte : il attestait la présentation d’une revendication liée à ce condensat, pas la remise des octets originaux. Cette différence paraît mince dans un formulaire, mais elle sépare l’observation d’un objet de l’observation d’un identifiant cryptographique de cet objet.

Le service vsd validait un document signé. Il ne se limitait pas au calcul de la signature : certificats, état de révocation, chaîne de confiance et politique entraient dans l’évaluation. Le service vpkc portait sur un ou plusieurs certificats à un instant donné. Il pouvait utiliser CRL, OCSP, annuaire ou autre DVCS comme sources. RFC 3029 précisait toutefois que ce mécanisme ne remplaçait pas CRL et OCSP dans les grands environnements ouverts.

Un même mot, « validation », recouvrait ainsi quatre propositions. Données remises, empreinte revendiquée, document signé acceptable, certificat acceptable : les confondre revenait à demander au jeton de prouver plus que le serveur n’avait observé.

Le résultat conservait les conditions de sa fabrication

Le DVC prenait la forme d’un objet CMS SignedData. Son contenu associait des informations de requête, une empreinte, un numéro de série strictement croissant, un temps de réponse, un état collectif, une politique et, selon le service, des résultats détaillés par certificat ou par signature. Le temps pouvait lui-même provenir d’un jeton externe, que le DVCS devait alors valider.

La vérification côté client ne s’arrêtait donc pas à la cryptographie de l’enveloppe. RFC 3029 demandait d’examiner le temps acceptable, le nom du serveur, la référence à la requête, l’empreinte, la signature, l’état, le type de service et la politique. Il fallait aussi valider le certificat de signature du DVCS. Une signature correcte sur une réponse mal rattachée ou rendue sous une politique inacceptable restait une réponse inutilisable.

La politique expliquait pourquoi deux serveurs pouvaient conclure différemment sans que l’un mente. Ils pouvaient faire confiance à des racines distinctes, demander un nombre différent de signatures ou utiliser des informations d’état différentes. Le DVC ne disait pas « cet objet est universellement valide ». Il disait quel serveur avait rendu quel résultat, quand, pour quelle empreinte et sous quelles règles.

Le collectif et le détail pouvaient diverger

Pour un ensemble de certificats, un échec collectif imposait de regarder quels éléments avaient échoué. Pour un document multisigné, une signature invalide ne condamnait pas nécessairement l’ensemble si la politique exigeait seulement un nombre suffisant de signatures. Le serveur pouvait alors produire grantedWithMods. À l’inverse, plusieurs signatures mathématiquement correctes pouvaient ne pas satisfaire une exigence globale. L’état granted était réservé au cas où toutes les signatures étaient vérifiées.

Le statut sommaire était donc un raccourci contrôlé, non le dossier complet. La mention WAITING ajoutait une autre limite : elle annonçait qu’une réponse finale viendrait plus tard selon la politique. Elle ne pouvait pas être transformée en autorisation provisoire par commodité.

Un verdict négatif signé n’était pas une erreur non signée

Si le service avait exécuté la validation, un DVC pouvait rapporter un résultat négatif authentique. Si la requête ne pouvait même pas être exécutée—format illisible ou authentification du demandeur défaillante—le serveur renvoyait une notification d’erreur. Ces deux refus ne racontaient pas la même histoire.

RFC 3029 isolait encore le cas où le serveur ne pouvait produire une signature valable, par exemple après compromission connue de sa clé. L’erreur pouvait apparaître dans une structure sans information de signataire, mais le client devait la traiter comme critique et fatale, sans faire confiance implicitement à son contenu. Un verdict signé disant « invalide » possède une autorité négative. Un message non signé ne l’hérite pas simplement parce qu’il semble prudent.

Publié en février 2001, RFC 3029 était expérimental et non une norme Internet. RFC 3379 puis RFC 5055 ont ensuite précisé d’autres modèles de validation déléguée. Rien dans ces textes ne permet d’inventer une adoption actuelle. La leçon historique est plus précise : déléguer l’analyse ne supprime pas la décision du destinataire. Cela rend indispensable la conservation de la question, de la politique et du résultat exact.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3029 ou les normes PKIX associées. Ses essais servent ici de cadres analytiques explicitement déclarés.