Résumé

  • Une extension X.509 v3 réunit un OID, un booléen critical faux par défaut et une valeur encodée ; l'ensemble appartient aux données signées du certificat.
  • Une extension critique inconnue ou impossible à traiter impose le rejet. Une extension non critique inconnue peut être ignorée, mais une extension reconnue doit être appliquée même si son indicateur vaut faux.
  • La criticité ne mesure ni la gravité ni la vérité. Elle répartit le risque de migration entre l'émetteur qui exige un sens et le logiciel qui doit être capable de l'exécuter.

Avant les extensions, le certificat avait des murs fixes

Le certificat décrit par RFC 1422 pour la messagerie PEM de 1993 tenait en sept grands éléments : version, numéro de série, signature, émetteur, période de validité, sujet et clé publique du sujet. Cette forme issue de X.509 de 1988 savait lier un nom à une clé. Elle n'offrait pas une galerie indéfinie où accrocher de nouvelles identités, de nouveaux usages et de nouvelles contraintes de délégation.

X.509 v3 ajouta donc une séquence d'extensions. Le premier profil Internet, RFC 2459, pouvait définir des extensions communes tout en laissant d'autres communautés enregistrer leurs propres identifiants. La structure extérieure du certificat n'avait plus besoin d'être redessinée pour chaque idée.

Cette souplesse déplaçait le problème vers le récepteur. Un programme ancien pouvait rencontrer un OID créé plusieurs années après sa livraison. S'il rejetait toute nouveauté, l'écosystème ne pouvait évoluer. S'il ignorait toute nouveauté, une contrainte signée n'engageait que les logiciels déjà convaincus de la lire.

Le booléen ne jugeait pas l'importance

RFC 5280 donne la mécanique qui a survécu. extnID nomme la sémantique au moyen d'un identifiant d'objet. extnValue contient la valeur encodée en DER dans une chaîne d'octets. Entre les deux, critical est un booléen dont la valeur par défaut est FALSE.

Un système qui ne reconnaît pas une extension critique doit refuser le certificat. Le refus s'impose également s'il reconnaît le type mais ne sait pas traiter les informations contenues. Une extension non critique inconnue peut être laissée de côté. En revanche, le qualificatif non critique n'autorise pas à négliger une extension reconnue : elle doit être traitée.

Ce n'est donc ni une priorité dans une file, ni une note de sécurité. Mettre TRUE ne renforce pas la signature et ne transforme pas l'affirmation de l'autorité de certification en fait incontestable. Le bit dit que le certificat ne doit pas produire d'effet chez un destinataire incapable d'appliquer ce sens précis.

Le choix est lui-même signé dans TBSCertificate. On ne peut pas changer le bit pendant le transport sans invalider la signature. Le même OID ne peut apparaître qu'une fois dans un certificat ; le validateur n'a pas à deviner quelle copie contradictoire aurait le dernier mot.

Des contraintes dont l'absence changeait l'autorité

La criticité devient claire lorsque l'on regarde les champs concernés. Si le champ sujet est vide et que l'identité n'existe que dans subjectAltName, cette extension doit être critique. La laisser invisible à un ancien validateur reviendrait à accepter une clé sans avoir traité son seul nom.

Dans un certificat d'autorité qui sert à vérifier les signatures d'autres certificats, basicConstraints doit être présente et critique. Elle dit notamment si la clé peut certifier et peut limiter la profondeur de la chaîne. Un logiciel qui l'ignore ne perd pas un commentaire : il perd la frontière de délégation.

nameConstraints borne les espaces de noms qu'une autorité intermédiaire peut transmettre plus bas dans le chemin. Le profil exige sa criticité. Une autorité limitée à certains domaines ne doit pas paraître universelle aux logiciels qui ne savent pas lire cette limite. Les contraintes de politique et inhibitAnyPolicy suivent la même logique : leur fonction est précisément de retirer des possibilités au chemin.

D'autres extensions restent volontairement non critiques. Elles peuvent aider à construire un chemin, à retrouver une information ou à enrichir une application sans rendre tout ancien programme incapable d'utiliser le certificat. La bonne question n'est donc pas « ce champ concerne-t-il la sécurité ? », mais « un destinataire peut-il employer correctement ce certificat sans ce sens ? ».

Le routage et TLS choisirent des coûts opposés

RFC 3779 appliqua le mécanisme aux droits d'usage sur des blocs d'adresses IP et des numéros de système autonome. Le document recommande des extensions critiques : une application qui utilise ce certificat pour son objet doit comprendre les ressources effectivement déléguées. Une signature valide sans la portée IP ou ASN ne suffit pas à rendre le résultat pertinent.

RFC 7633 fit un autre arbitrage pour l'extension TLS Feature. Elle ne devrait normalement pas être critique, car les implémentations anciennes rejetteraient alors le certificat. Le texte ne dit pas que l'extension est sans effet. Il réserve la rupture aux cas où l'on veut véritablement exclure les clients incapables de la comprendre.

Le bit place ainsi le coût à un endroit identifiable. Avec FALSE, l'émetteur garde la compatibilité, mais ne peut promettre que tous les clients ont appliqué la nouveauté. Avec TRUE, il protège le caractère obligatoire de la règle, mais accepte que les clients non préparés échouent proprement.

Le validateur réalisait ce que la norme avait publié

RFC 3280 détailla en 2002 un algorithme de validation de chemin où les extensions critiques devaient être reconnues et traitées. RFC 5280 conserva ce résultat. Une implémentation peut organiser ses fonctions autrement, mais elle ne peut terminer avec succès en laissant derrière elle un sens critique inconnu.

Cette règle sépare la coordination de l'autorité opérationnelle. L'IETF peut publier un OID. Une autorité peut signer sa valeur. La réalité change seulement lorsque le code du destinataire sait décoder, évaluer et, si nécessaire, refuser. La publication rend la décision testable ; elle ne force pas magiquement les machines à l'avoir adoptée.

La continuité apparaît encore dans RFC 9618, qui actualisa en 2024 la validation des politiques X.509. Une application qui n'a pas besoin de cette validation peut la désactiver. Mais elle doit alors traiter les extensions critiques liées aux politiques comme inconnues et rejeter le chemin. Retirer une capacité ne donne pas le droit d'imiter son résultat.

Ce refus restait un verdict limité

Le succès de la validation ne prouve pas l'honnêteté du sujet, la qualité de l'enquête de l'émetteur ou l'absence de compromission de la clé. Il montre seulement qu'un chemin, un ancrage de confiance, une date, des signatures et les contraintes applicables ont satisfait les règles du validateur et de l'application.

Un OID connu peut contenir une valeur mal formée. Une valeur bien formée peut violer une contrainte. Plusieurs chemins vers le même certificat peuvent traverser des intermédiaires différents. La criticité empêche le silence face à un sens obligatoire ; elle n'abolit ni la politique locale ni les erreurs de l'autorité.

Les sources fixent aussi les limites de l'enquête. RFC 1422, RFC 2459, RFC 3280, RFC 5280, RFC 3779, RFC 7633 et RFC 9618 décrivent l'histoire, la syntaxe et le comportement spécifié. Ils ne fournissent ni part de marché actuelle, ni fréquence de panne, ni preuve de conformité de tous les navigateurs ou bibliothèques.

L'invention de X.509 v3 ne fut donc pas seulement une réserve de nouveaux champs. Son petit bit critique empêchait l'extension de devenir une promesse creuse : lorsqu'un nouveau sens était indispensable, ne pas le comprendre devait rester visible sous la forme d'un refus.