Résumé

  • RFC 5276 impose une correspondance précise entre chaque information renvoyée par SCVP et l’EvidenceRecord qui la protège ; une valeur vide signale que cette preuve n’est pas disponible.
  • Ni la présence ni l’absence de cette preuve ne décide seule de la validité du certificat, de l’acceptation de l’ancre de confiance ou de l’autorisation finale de l’application.

Une demande arrive auprès d’un serveur SCVP. Le client veut le chemin de certification et la preuve que ce chemin a été conservé dans le temps. Le serveur peut renvoyer le chemin, mais pas l’EvidenceRecord demandé. RFC 5276 lui ordonne alors de conserver la forme de la réponse et de laisser vide la valeur de la preuve.

Ce vide est une information exacte. Il ne dit pas « certificat invalide ». Il ne dit pas non plus « tout va bien ». Il dit que le serveur ne peut pas fournir, pour cet élément précis, la preuve de conservation sollicitée.

Cette distinction paraît modeste. Elle protège pourtant le système contre l’un de ses raccourcis les plus dangereux : transformer une lacune documentaire en jugement cryptographique, ou inversement transformer une enveloppe cryptographique bien formée en autorisation générale. RFC 5276 organise des liaisons de preuve. Il ne fabrique pas un oracle universel.

Deux axes qu’un tableau de bord ne doit pas fusionner

SCVP sert à construire ou valider un chemin de certification selon une politique, un instant et des paramètres donnés. ERS, l’Evidence Record Syntax, sert à montrer que des données déterminées existaient avec leur intégrité à une certaine date, puis à prolonger cette démonstration lorsque les algorithmes ou certificats de datation vieillissent.

RFC 5276 permet de demander ces deux choses ensemble. Le client utilise des identifiants WantBack pour obtenir un certificat, un chemin complet, un chemin partiel ou des informations de révocation, puis d’autres identifiants pour recevoir l’EvidenceRecord couvrant le résultat correspondant.

On obtient donc au moins deux axes indépendants. Sur le premier, le serveur a-t-il produit un statut et les éléments de chemin demandés selon la politique indiquée ? Sur le second, dispose-t-il d’une preuve à long terme couvrant exactement ces éléments ? Une réponse peut être positive sur un axe et incomplète sur l’autre.

La supervision doit conserver cette matrice. « Requête comprise », « élément renvoyé », « preuve associée présente », « preuve vérifiée » et « conclusion de validation » ne sont pas des synonymes. Une seule pastille verte les rend indiscernables au moment où une enquête en a le plus besoin.

Une preuve doit désigner ce qu’elle couvre

Le texte ne se contente pas d’attacher un bloc ERS à la réponse entière. Pour un chemin complet, l’EvidenceRecord couvre la valeur DER du CertBundle renvoyé. Pour un certificat isolé, il couvre la valeur du certificat dans la réponse. Pour les informations de révocation, il faut pouvoir associer chaque CRL ou réponse OCSP à une preuve ; un même EvidenceRecord peut couvrir plusieurs éléments, mais le hachage de l’élément doit être retrouvé dans la première horodatation initiale.

La forme agrégée EvidenceRecordWantBacks rend cette discipline visible. Chaque entrée indique par targetWantBack le type de donnée protégée. Le standard exige une correspondance un pour un avec les autres réponses WantBack. Lorsqu’aucune preuve n’existe pour une donnée, le champ evidenceRecord de cette entrée est absent.

Cette comptabilité empêche l’ambiguïté par proximité. Une preuve valide placée à côté d’un chemin ne suffit pas ; il faut démontrer qu’elle couvre le chemin effectivement renvoyé. De même, une preuve couvrant une CRL ne couvre pas automatiquement une autre CRL, une réponse OCSP ou le certificat final.

Le contrôle pertinent est donc une relation vérifiable : type demandé, octets renvoyés, empreinte couverte, chaîne d’horodatages, résultat de vérification. La conservation n’est fiable que si cette relation reste reproductible sans interprétation institutionnelle.

Le chemin partiel économise l’espace et déplace le risque

RFC 5276 prévoit un chemin complet allant du certificat final jusqu’à l’ancre de confiance, mais aussi un chemin partiel commençant à l’autorité qui a émis le certificat final. Dans ce second modèle, le certificat du signataire peut être conservé avec le document archivé, tandis que SCVP préserve la partie commune du chemin et les informations de révocation.

L’économie est réelle. Plusieurs documents de la même période peuvent réutiliser la même portion d’infrastructure sans dupliquer un chemin complet. Mais l’économie déplace l’obligation de preuve vers le futur vérificateur.

Celui-ci doit retrouver le certificat final, vérifier qu’il était bien protégé avec le document, vérifier la signature du document, relier ce certificat au chemin partiel, appliquer la bonne politique et examiner les informations de révocation pertinentes. Le chemin partiel peut être intact alors que le certificat final manque. Le certificat peut être intact alors que la signature du document ne correspond pas. Tous les fichiers peuvent exister alors que personne n’a conservé la règle expliquant comment les assembler.

La bonne question d’architecture n’est donc pas seulement « combien d’octets économisons-nous ? ». Elle est « quelle dépendance reportons-nous sur l’équipe qui devra reconstruire la décision dans vingt ans ? ».

L’ancre ne tire pas son autorité du paquet

RFC 5280 définit l’ancre de confiance comme une entrée du processus de validation. Des applications différentes peuvent choisir des ancres différentes. Un chemin acceptable pour l’une peut être refusé par l’autre, même si toutes deux exécutent correctement l’algorithme.

SCVP conserve cette diversité. La requête peut préciser la politique de validation, l’instant, les ancres admises, les usages de clé, les usages étendus et les contrôles de révocation. Si le client s’appuie sur les valeurs par défaut du serveur, il simplifie la requête mais doit ensuite conserver suffisamment d’informations pour expliquer quelles valeurs ont réellement gouverné le résultat.

RFC 5276 ajoute que la signature de la réponse SCVP doit être vérifiée avec une clé publique à laquelle la partie utilisatrice fait confiance. La réponse peut transporter des ancres servant à vérifier des couches internes d’ERS. La partie utilisatrice peut les accepter ou les ignorer au profit d’ancres obtenues hors bande. Si la réponse n’est pas signée, elle devrait ignorer les ancres qu’elle contient.

Ainsi, une ancre n’acquiert pas une autorité universelle parce qu’elle voyage dans une réponse préservée. Sa provenance et son acceptation restent des décisions locales. Le paquet peut protéger son transport ; il ne peut pas contraindre la politique de celui qui le reçoit.

Le temps demandé n’est pas le temps de toute connaissance

La validation historique est nécessaire : un certificat expiré aujourd’hui pouvait être valide lorsque le document a été signé. Le champ validationTime permet de poser cette question au serveur, qui doit disposer des informations historiques appropriées ou renvoyer une erreur.

RFC 5055 précise cependant que le statut connu à l’instant demandé peut ne pas être l’information la plus complète découverte plus tard. Une révocation publiée après la première consultation peut indiquer une date d’invalidité antérieure à validationTime. Une ancienne réponse affirmative peut donc être authentique, correctement calculée et fidèlement conservée, puis cesser d’être la meilleure base pour une décision présente.

Il faut préserver deux chronologies : la période à laquelle le certificat est évalué et la période à laquelle chaque information est entrée dans le dossier. Sans la seconde, l’archive transforme une photographie ancienne en conclusion éternelle.

Le nonce de la requête et la protection de la réponse appartiennent à cette même hygiène. Si le client ne vérifie pas la signature ou le MAC, ou s’il ne compare pas le nonce, une réponse ancienne peut être modifiée ou rejouée. La longévité ne corrige pas une acquisition mal authentifiée ; elle la rend seulement durable.

ERS est une politique d’entretien

Un EvidenceRecord ne reçoit pas l’éternité au moment de sa création. RFC 4998 organise une suite d’horodatages d’archive. Avant que la signature de l’horodatage ou son certificat ne deviennent insuffisants, un renouvellement couvre l’horodatage précédent. Si l’algorithme de hachage de l’arbre devient faible, un renouvellement de l’arbre couvre les anciennes preuves et les données archivées sous une nouvelle construction.

La preuve durable est donc un service continu. Elle exige une veille sur les algorithmes, les certificats de datation, les politiques d’acceptation et les données nécessaires pour vérifier les anciennes couches.

Le champ cryptoInfos illustre encore la limite. Il peut contenir des ancres, certificats, données de révocation ou indications sur la robustesse historique des algorithmes. RFC 4998 avertit que ces informations ne sont pas protégées dans un horodatage et doivent être vérifiées par d’autres moyens. Leur présence aide ; elle ne les authentifie pas.

La chaîne complète doit rester lisible

Un dossier historique défendable relie le document archivé à sa signature, au certificat utilisé, à l’instant demandé, à la politique SCVP, aux ancres acceptées, à la réponse authentifiée, aux éléments renvoyés, aux EvidenceRecords correspondants, à leur historique de renouvellement, aux informations ultérieures qui corrigent le dossier et à la décision propre à l’application.

Cette chaîne permet des réponses nuancées. Une preuve manquante peut justifier une investigation sans transformer le certificat en fraude. Une politique devenue plus stricte peut refuser aujourd’hui un chemin accepté hier sans nier l’existence de l’ancienne décision. Une révocation rétrospective peut remplacer la conclusion tout en préservant l’authenticité du premier rapport.

La précision de RFC 5276 est donc moins une célébration de l’archive qu’une défense contre son pouvoir symbolique. Ce qui a été conservé mérite d’être lu exactement. Ce qui n’a pas été prouvé ne doit pas être ajouté par le vocabulaire.