Résumé

  • La RFC 9608 permet à une autorité de certification d'indiquer par noRevAvail qu'elle ne publiera aucune information de révocation pour un certificat d'entité finale. Le validateur omet alors une étape ; il ne reçoit pas un état positif.
  • Les certificats de courte durée et certaines identités matérielles de très longue durée peuvent justifier ce choix, mais l'extension ne mesure ni le temps de détection, ni le retrait local, ni le remplacement.
  • Un reçu local et minimisé du cycle de vie sans révocation peut relier le profil, la décision d'admission, les signaux de compromission et le chemin de reprise. Il s'agit d'une proposition éditoriale de Daniel Kade, non d'une nouvelle extension X.509.

Le certificat de six heures paraît résoudre le problème par le calendrier. S'il expire avant qu'une liste de révocation ou une réponse OCSP ne puisse protéger qui que ce soit, pourquoi entretenir une infrastructure de statut ? La RFC 9608 donne une forme interopérable à ce raisonnement. Elle ne transforme pas, pour autant, une durée choisie en preuve de sécurité.

Publiée en juin 2024 comme norme proposée de l'IETF, la RFC met à jour la validation décrite par la RFC 5280. L'extension noRevAvail déclare que l'autorité de certification ne rendra pas disponible d'information de révocation pour ce certificat. Sa valeur est NULL, elle n'est pas critique et elle est réservée aux certificats d'entité finale. Une CA ne doit pas la placer dans son propre certificat.

Cette déclaration est utile parce qu'elle écarte une ambiguïté opérationnelle. L'absence d'une adresse OCSP n'est plus nécessairement un oubli ; l'absence d'une CRL n'est plus un incident transitoire. L'émetteur annonce qu'il n'existera pas de source de statut pour ce certificat. Le logiciel peut éviter une requête vouée à l'échec.

Mais l'absence de source n'est pas un état « bon ». Elle ne dit pas que la clé est encore secrète, que son détenteur conserve son mandat, que le service accepte toujours ce type de certificat, ni qu'un remplacement serait possible demain. Elle décrit une branche de protocole, non la totalité de la relation de confiance.

Omettre un contrôle n'équivaut pas à le réussir

Dans le traitement normal d'un chemin de certification, la RFC 5280 demande notamment de déterminer que le certificat n'est pas révoqué. La RFC 9608 modifie cette étape : elle est sautée lorsque noRevAvail est présent, ou dans le cas spécialisé où ocsp-nocheck s'applique au certificat d'un répondeur OCSP.

Le vocabulaire compte. Une étape omise ne renvoie ni « révoqué » ni « non révoqué ». Elle signale que ce profil ne fournit pas le mécanisme permettant de poser la question. Une interface qui affiche simplement « valide » peut être correcte au niveau du chemin cryptographique tout en devenant trompeuse au niveau de l'autorisation présente.

La RFC impose donc une cohérence syntaxique sévère. Un certificat marqué noRevAvail ne doit contenir ni points de distribution de CRL, ni Freshest CRL, ni méthode OCSP dans Authority Information Access. La coexistence serait contradictoire et le certificat doit être rejeté. L'émetteur ne peut pas dire simultanément « aucune information ne sera publiée » et « voici où la demander ».

Cette règle fournit un modèle de gouvernance. Si la politique d'une application exige une preuve de révocation, elle ne peut pas admettre silencieusement un profil qui promet l'absence de cette preuve. Elle peut refuser le certificat, ou créer une classe d'admission explicite fondée sur d'autres contrôles. Elle ne peut pas résoudre la contradiction en colorant l'ensemble du dossier en vert.

La distinction avec ocsp-nocheck évite une autre confusion. Ce dernier est conçu pour des certificats de répondeur OCSP et possède son propre contexte. noRevAvail ne doit pas devenir un remplacement approximatif. Un journal d'exécution sérieux indique quelle extension a causé l'omission et pour quel type de certificat.

La courte durée dépend de quatre horloges

Le raisonnement en faveur d'un certificat éphémère compare au moins quatre délais. Il faut détecter une compromission, la signaler, décider d'une réponse, puis distribuer ou exécuter cette réponse. Si le certificat expire avant la fin de cette chaîne, la publication d'un statut peut arriver trop tard pour réduire l'exposition.

La RFC 9608 reconnaît cet intérêt, tout en avertissant qu'une durée insuffisamment courte crée une fenêtre d'opportunité pour l'attaquant. Elle ne donne pas de nombre magique, car le nombre dépend du système. Une heure peut être longue pour une autorité de signature automatisée et courte pour un équipement qui ne se reconnecte qu'une fois par semaine.

L'automatisation ne supprime pas cette comparaison. ACME peut rendre l'acquisition et le renouvellement rapides et fiables. Cependant, un client qui possède encore une clé volée peut parfois renouveler aussi vite qu'un client légitime. Le fait de produire un nouveau certificat toutes les heures n'est pas la preuve que l'autorité du demandeur a été réévaluée chaque heure.

Une organisation doit donc mesurer la durée restante au moment où un signal devient exploitable. Elle doit savoir si l'émission peut être arrêtée, si l'identité locale peut être désactivée, si une nouvelle clé est requise, si les services retirent l'ancienne association et combien de temps dure le chevauchement. « Courte durée » devient alors une propriété testée, non une étiquette commerciale.

Le risque change aussi avec l'usage. Un certificat servant à une opération rare et réversible n'a pas le même coût d'exposition qu'une identité autorisant des milliers d'actions irréversibles. La bonne fenêtre résulte du mécanisme d'impact, pas seulement de la fréquence de renouvellement.

Les identités longues déplacent la décision

La RFC 9608 décrit également des certificats de longue durée, notamment des identités installées en usine dans des appareils. Certaines n'ont pas de date de fin bien définie. Une date très lointaine peut représenter ce modèle sans signifier que le dispositif, son propriétaire, son logiciel, son algorithme et sa clé resteront fiables jusque-là.

Dans ce cas, l'émetteur peut ne disposer d'aucun canal permettant au propriétaire de notifier la compromission du matériau de clé installé. Il ne peut donc pas publier un état individuel utile. La franchise de noRevAvail vaut mieux qu'une URL de révocation fictive, mais elle déplace le poids vers les contrôles de terrain.

Un appareil change de main. Son fabricant cesse le support. Un opérateur retire un modèle. Une clé est extraite d'un composant. Une politique cryptographique interdit un algorithme. Le certificat peut continuer à vérifier pendant que l'autorité opérationnelle disparaît. Ce n'est pas une contradiction technique : ce sont deux couches différentes.

Le service doit posséder ses propres gestes de retrait. Il peut mettre un appareil en quarantaine, supprimer une association entre certificat et rôle, fermer un compte, arrêter une charge de travail ou refuser une empreinte. Ces gestes ne sont pas une révocation X.509 et ne doivent pas être présentés comme tels. Ils sont des confinements locaux dont la portée doit être documentée.

Le remplacement forme encore un autre état. Une nouvelle enveloppe autour de la même clé compromise ne suffit pas. Une nouvelle clé sans retrait de l'ancienne autorisation ne suffit pas davantage. Il faut générer, enregistrer, associer, déployer, désactiver l'ancien chemin et observer que le trafic légitime a basculé.

La révocation de la CA révèle l'échelle du défaut

Les considérations de sécurité de la RFC 9608 décrivent un cas extrême. Une mauvaise utilisation de l'extension peut conduire les parties dépendantes à continuer de faire confiance à un certificat compromis. Une fois ce mauvais usage découvert, le seul remède possible qu'elle nomme au niveau de la PKI est la révocation de la CA.

Ce n'est pas une procédure ordinaire de retrait individuel. Révoquer une CA peut toucher une population entière de certificats valides. Les magasins de confiance ne se mettent pas à jour ensemble, les systèmes hors ligne réagissent plus tard, et certaines applications ont leurs propres ancrages. Le remède montre pourquoi une décision de profil a une portée institutionnelle.

La partie dépendante a donc besoin de confiance dans les opérations de la CA, ses contrôles et sa réponse aux incidents. La RFC 3647 distingue utilement la politique de certification, qui énonce des exigences pour une communauté ou une classe, de la déclaration des pratiques de certification, qui explique comment l'autorité met ses procédures en œuvre. noRevAvail ne contient ni l'une ni l'autre.

Le reçu local doit lier le certificat à une version précise du profil, de la politique et, lorsque c'est pertinent, de la déclaration de pratiques. Il doit préserver la raison du choix : durée brève par rapport à quels délais, identité de dispositif sous quel modèle de remplacement, population limitée par quelle règle ? Une justification générique comme « certificats courts » ou « appareils » ne permettra aucune révision.

L'autorité de certification possède le profil d'émission. L'application possède le choix d'admission. Le responsable d'actif possède l'information sur l'état du dispositif. L'équipe d'incident possède les signaux de compromission. Confondre ces pouvoirs dans la seule validation de chemin retire à chacun son obligation explicite.

Une validation présente ne prouve pas un mandat présent

La validation cryptographique répond à des questions rigoureuses : signatures, chaîne d'émetteurs, contraintes, période, politiques applicables. Avec noRevAvail, elle répond en outre que l'étape de révocation n'est pas requise par ce profil. Elle ne consulte pas le contrat d'un employé, le registre de propriété d'un appareil, l'inventaire d'un service ni le résultat d'une enquête.

Il serait injuste de demander à X.509 de connaître ces faits. Le défaut est organisationnel lorsqu'une application traite son résultat comme un substitut. « Le chemin est valide » ne signifie pas « le sujet est encore autorisé à cette minute ». La seconde proposition exige des données et une décision locales.

La pensée de Heng Lu permet de maintenir cette frontière. Une spécification minimale crée un vocabulaire commun. Les acteurs l'adoptent volontairement dans un contexte local. Le code en fonctionnement applique une interprétation et les effets observés renvoient de l'information vers la décision. La norme ne devient pas l'institution complète.

Une interface fidèle peut donc montrer plusieurs états : chemin valide, révocation indisponible par profil, admission locale active, prochaine revue à une date donnée, signaux de risque normaux ou dégradés. Chaque état peut évoluer sans falsifier les autres. Cette granularité est une capacité de gouvernance, non un détail d'interface.

Le reçu de cycle de vie sans révocation

La réparation proposée ici est locale et minimisée. À l'admission, un reçu associe les empreintes du certificat et de l'émetteur, l'identité du profil, les versions CP/CPS, la raison de noRevAvail, le modèle de validité, l'application concernée, la règle d'admission et le propriétaire de la décision. Il note que les pointeurs CRL et OCSP contradictoires ont été absents.

Pendant l'exploitation, il référence les signaux de compromission, l'état de garde de la clé, l'état de l'appareil ou de la charge, les avis de l'émetteur et l'horloge de révision. Des empreintes, dates et conclusions limitées suffisent souvent. Le reçu ne doit contenir ni clé privée, ni dossier complet du sujet, ni topologie propriétaire, ni liste publique d'appareils non révocables.

Pour la reprise, il nomme le moyen de désactivation locale, la génération d'une nouvelle clé, le réenrôlement, le retrait de l'ancienne association, l'escalade vers l'émetteur et le plan de changement d'ancrage si le défaut est systémique. Le résultat final dit si l'ancien pouvoir a réellement cessé de fonctionner, pas seulement si un ticket a été fermé.

Ce reçu n'est ni une CRL, ni une réponse OCSP, ni une extension, ni une exigence de l'IETF. Il ne crée aucun statut mondial. Il prouve seulement qu'une organisation a accepté l'absence d'un canal dans des limites nommées, avec des contrôles compensatoires et une voie de sortie.

La RFC 9608 accomplit un progrès précis : elle rend l'absence interopérable. Le travail de gouvernance consiste à ne pas prendre cette absence explicite pour une preuve imaginaire. Aucun canal de révocation ne veut pas dire qu'aucun canal de révocation n'existera. Cela ne veut pas dire qu'aucun événement futur ne pourra retirer la confiance.

Sources