Résumé

  • Dans le texte de base désigné par SC-104, l’extension non critique Authority Information Access est obligatoire dans un certificat d’abonné TLS. La méthode id-ad-caIssuers y est toutefois un SHOULD, tandis que id-ad-ocsp est un MAY.
  • Le diff immuable du scrutin ne modifie que deux lignes : présence de l’extension de MUST à SHOULD, puis ajout de « If present » devant l’obligation d’avoir au moins un AccessDescription.
  • Les règles propres aux méthodes ne changent pas. caIssuers sert à obtenir un certificat d’émetteur pour construire un chemin ; OCSP désigne un service de statut en ligne. Une URL de l’un ne prouve rien sur l’autre.
  • La période de vote annoncée se termine le 3 septembre 2026 à 00 h 00 UTC. À la clôture de cette recherche, le 2 septembre, aucun résultat final, examen IPR achevé ou texte publié ne pouvait être attribué au scrutin.
  • L’audit doit distinguer l’état de procédure, la règle du profil, la règle de chaque méthode, les octets réellement émis et l’observation d’une partie utilisatrice. Ces états peuvent être reliés, mais jamais confondus.

Trois colonnes que le mot « AIA » masque

Un rapport de conformité présente volontiers une seule colonne : AIA présente, oui ou non. Le texte normatif en contient au moins trois.

La première colonne décrit l’extension. Au commit de base ad77bf…, le tableau des extensions du certificat d’abonné exige authorityInformationAccess avec le mot MUST et précise qu’elle n’est pas critique. La deuxième colonne décrit le contenu : AuthorityInfoAccessSyntax doit contenir un ou plusieurs AccessDescription. La troisième sépare les méthodes : OCSP est permis (MAY), caIssuers est recommandé (SHOULD), et toute autre valeur est interdite.

Cette architecture garantit donc un conteneur non vide, mais pas la présence d’un service particulier. Elle peut sembler déséquilibrée sans être incohérente : les contraintes de syntaxe, d’URI, d’unicité et d’ordre restent effectives. La question de SC-104 est plus modeste : le niveau obligatoire du contenant doit-il être rapproché des niveaux moins absolus du contenu ?

Le texte proposé répond par deux opérations. Il remplace le MUST extérieur par SHOULD. Il rend la règle de cardinalité conditionnelle à la présence de l’extension. Il ne touche ni aux OID, ni aux finalités, ni aux niveaux intérieurs, ni aux profils des certificats de CA ou de répondeur OCSP.

Dire que « tout devient facultatif » effacerait précisément la différence que le scrutin laisse intacte.

L’exception à SHOULD doit rester visible

Dans le langage RFC, SHOULD n’est pas une décoration. RFC 2119 autorise une dérogation lorsqu’il existe des raisons valables, mais demande d’en comprendre et d’en peser soigneusement les conséquences. RFC 8174 encadre l’emploi de ces mots en capitales.

Si le scrutin franchit toutes les étapes et si une CA émet ensuite un certificat sans AIA, deux jugements doivent donc rester séparés. Le premier est formel : l’absence ne violerait plus une exigence MUST de présence. Le second est documentaire : la CA devrait être capable d’expliquer pourquoi elle s’écarte d’un SHOULD, pour quel produit, avec quel profil de délivrance et après quels essais.

Une base de données réduite à present=false perd cette seconde information. Elle place sur le même plan une exception étudiée, une configuration ancienne et une omission accidentelle. Elle empêche également de savoir si la CA a supprimé tout le conteneur ou seulement l’une des méthodes.

Un bon registre conserve donc le terme normatif littéral. Il n’interprète pas SHOULD comme MAY pour simplifier une interface, et il n’invente pas non plus une interdiction de déroger. La raison, la portée et la version de configuration deviennent des champs d’exécution locaux.

caIssuers et OCSP ne répondent pas à la même question

RFC 5280 décrit l’AIA comme une séquence d’informations ou de services concernant l’émetteur. Sous cette enveloppe commune, les deux identifiants suivis ici conduisent à des mécanismes différents.

id-ad-caIssuers indique où obtenir un certificat de l’émetteur. Une partie utilisatrice peut s’en servir pour choisir ou construire un chemin de certification. id-ad-ocsp indique où interroger un service de statut de certificat. La construction de chaîne et l’information de statut peuvent se rencontrer dans une validation, mais elles ne sont pas interchangeables.

Cette différence apparaît aussi dans les Baseline Requirements. D’autres règles, notamment relatives aux CRL, examinent spécifiquement la présence d’un pointeur OCSP dans l’AIA. Une observation qui note seulement « AIA supprimée » ne permet pas de reconstruire ces effets. Il faut une ligne par méthode, avec OID, niveau, emplacement et fonction.

L’absence de caIssuers ne prouve pas, à elle seule, qu’une chaîne sera impossible à bâtir. Le serveur TLS peut fournir l’intermédiaire approprié. Le client peut déjà le posséder, l’avoir mis en cache ou l’avoir reçu par un canal de distribution. Symétriquement, une URL caIssuers présente ne prouve ni qu’un client la consultera, ni qu’elle sera joignable, ni que le certificat obtenu conduira à un chemin valide.

Le certificat donne une adresse possible. Il ne raconte pas l’exécution.

L’exécution change avec la configuration, pas seulement avec la marque

La documentation Microsoft explique que Windows peut récupérer un certificat d’émetteur manquant au moyen de l’AIA. Elle explique aussi que l’administrateur peut désactiver ce comportement. Une mesure sérieuse doit donc indiquer la version, la stratégie, l’état du cache, le réseau et la chaîne envoyée par le serveur. La phrase « testé sous Windows » ne suffit pas.

Mozilla a documenté en 2020 le préchargement, via Remote Settings, de certificats intermédiaires déclarés. Cette distribution visait notamment à réduire les erreurs d’émetteur inconnu provoquées par des sites qui n’envoient pas l’intermédiaire correct. Le mécanisme illustre une autre origine possible de la chaîne ; il ne garantit pas que chaque intermédiaire est disponible dans chaque version, ni que l’opérateur du serveur peut négliger sa configuration.

Ces deux exemples bornés sont plus instructifs qu’une moyenne imaginaire. Un poste d’entreprise ayant désactivé la récupération, un navigateur dont le cache est déjà rempli et une bibliothèque TLS embarquée peuvent traiter le même certificat de trois manières. SC-104 ne commande aucune de ces implémentations.

Il serait également dangereux de transformer une capacité de secours du client en règle de livraison du serveur. La possibilité de récupérer un intermédiaire manquant n’autorise pas en général un service TLS à présenter une chaîne incomplète. Le scrutin ajuste un profil de certificat, pas le protocole de poignée de main.

Le scrutin n’est pas encore le texte applicable

L’avis public nomme Ethan Davis, de Google Trust Services, comme proposant, et Roman Fischer, de SwissSign, ainsi que Stephen Davidson, de DigiCert, comme endosseurs. Il rattache SC-104 à la version 2.2.9 des Baseline Requirements et à une comparaison immuable entre le commit de base et le commit proposé.

La discussion était annoncée du 20 au 27 août 2026 UTC, puis le vote du 27 août au 3 septembre à 00 h 00 UTC. Le 2 septembre, la seule qualification prudente est donc en période de vote. Un pull request ouvert, un résultat favorable, l’achèvement de l’examen IPR et la publication d’une Final Maintenance Guideline sont quatre états différents.

Cette chronologie est un élément substantiel de gouvernance. Une proposition peut être techniquement précise sans encore disposer de l’autorité normative. Un vote favorable, s’il intervient, n’antidate pas la règle. Un échec n’efface pas le fait que le texte a été soumis. Une modification ultérieure ne doit pas être attribuée silencieusement au commit analysé ici.

Le reçu procédural devrait enregistrer les commits, les fenêtres de discussion et de vote, les collèges et dénominateurs, le résultat, l’examen IPR, les éventuelles exclusions, la version finale et sa date d’effet. Chaque événement ajoute une ligne ; le dernier statut ne remplace pas les précédents.

Cinq reçus pour une seule observation complète

Reçu de procédure. Il identifie SC-104 et répond à la question d’autorité : proposition, vote, IPR, publication. Il ne dit pas ce qu’une CA a déployé.

Reçu de profil. Il nomme le type de certificat, la version des Guidelines, la criticité et le niveau exact de présence de l’AIA. Il dit quelle règle s’applique à une classe définie.

Reçu de méthode. Il conserve caIssuers et OCSP sur deux lignes, avec OID, objectif, SHOULD ou MAY, type d’emplacement, multiplicité et ordre. Il empêche le conteneur d’avaler les différences internes.

Reçu d’émission. Il associe la CA, le produit, le modèle de délivrance et sa version à l’empreinte d’un certificat. Il relève l’AIA et chaque description effectivement encodée. Il décrit des octets.

Reçu d’utilisation. Il associe la même empreinte à un produit client, une version, une plate-forme, une stratégie, un magasin, un cache ou préchargement, la chaîne du serveur et les conditions réseau. Il indique la source de l’intermédiaire, les requêtes et le résultat. Il décrit une expérience reproductible.

La puissance de ce modèle tient aux jointures. La version relie la règle à l’émission ; l’empreinte relie l’émission au test. Mais une validation réussie ne prouve pas que l’AIA a été utilisée. Un échec local ne rend pas le scrutin invalide. Une règle publiée ne prouve pas qu’un modèle d’émission a changé.

Le principe de Lu Heng sur une spécification commune minimale et des décisions futures localement vérifiables éclaire cette séparation. Il ne constitue pas une approbation de SC-104. Il rappelle simplement qu’un texte commun, son adoption et son exécution sont des objets différents, dont chacun doit porter sa propre preuve.

Une justification logique n’est pas une étude d’impact

Le dossier public ne mesure pas la fréquence actuelle de l’AIA, de caIssuers ou d’OCSP dans les certificats d’abonné. Il ne recense pas les CA qui modifieraient leurs modèles. Il ne quantifie ni taille, ni latence, ni confidentialité, ni disponibilité, ni incidents. Il n’établit pas qu’une partie utilisatrice particulière ait demandé le changement.

La justification de SC-104 peut néanmoins être cohérente : une enveloppe MUST ne garantit aucun service précis lorsque les services autorisés sont SHOULD et MAY. Cette cohérence ne préjuge pas du bénéfice opérationnel. Elle ouvre une question de norme ; les conséquences doivent être mesurées séparément.

Les deux camps ont donc la même obligation de précision. L’existence de préchargements ne prouve pas l’innocuité universelle d’une omission. L’existence d’une récupération AIA ne prouve pas une dépendance universelle. Le bon test segmente certificats, serveurs, clients et configurations.

Une petite règle mérite un constat plus étroit

Le Working Group peut décider d’aligner le niveau extérieur sur la réalité des méthodes intérieures. Les CA peuvent conserver l’AIA par défaut, documenter une exception ou ne rien changer. Les fournisseurs de clients peuvent maintenir leurs stratégies, et les exploitants de serveurs restent responsables de la chaîne qu’ils présentent.

Un seul slogan ne peut attribuer correctement ces décisions. « AIA est devenue optionnelle » perd la force de SHOULD. « Les clients n’en ont plus besoin » invente un résultat. « Le scrutin impose une nouvelle pratique » saute les étapes de procédure et de déploiement.

Le constat défendable tient en trois phrases vérifiables : telle version a autorisé tel texte ; tel certificat porte telles descriptions ; tel client, dans telles conditions, a obtenu tel résultat. Le registre à cinq états permet de les écrire sans que l’une serve de preuve à l’autre.

Pour deux lignes de diff, c’est suffisamment précis—et suffisamment modeste.

Sources

  1. Lu Heng, « Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption »
  2. CA/Browser Forum, pull request servercert 665 — SC-104
  3. Comparaison immuable de SC-104
  4. CA/Browser Forum, issue servercert 673
  5. Archive publique de l’avis de vote SC-104
  6. TLS Baseline Requirements au commit de base du scrutin
  7. Statuts du CA/Browser Forum
  8. RFC 5280, section 4.2.2.1
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, récupération Authority Information Access
  12. Mozilla Security Blog, préchargement des certificats de CA intermédiaires dans Firefox