Résumé

  • RFC 3709 autorise des logotypes associés à un certificat, mais les exclut explicitement de la validation automatique du chemin de certification.
  • L’empreinte confirme que les octets récupérés correspondent à la référence du certificat ; elle ne prouve ni la validité du chemin ni la légitimité du logo.

Deux lectures, deux objectifs

Un certificat est d’abord traité par une machine : elle vérifie un chemin, des signatures, des noms, des contraintes et une politique. Il peut aussi être présenté à une personne qui doit reconnaître un interlocuteur ou départager plusieurs certificats convenables. RFC 3709 répond à ce second besoin. Ses auteurs constataient que les champs d’un certificat sont peu accessibles et que, dans certains usages, une personne doit choisir elle-même entre plusieurs possibilités.

Le risque apparaît dès que l’on place un signe visuel dans le même objet signé que des éléments utilisés par la machine. L’image semble alors bénéficier de la même force probante que le certificat entier. RFC 3709 trace une ligne nette : le logotype est destiné à l’interprétation humaine et ne doit pas devenir un composant actif de la validation du chemin. RFC 9399, qui a remplacé RFC 3709 et RFC 6170 en 2023, conserve cette séparation. La vérification automatique et la reconnaissance humaine peuvent se compléter ; elles ne répondent pas à la même question. RFC 3709 §1.3 RFC 9399 §§1.3, 6

Le certificat pointait vers l’image

Au lieu d’embarquer chaque fichier image ou audio, l’extension pouvait porter des URI ainsi qu’une empreinte cryptographique des données référencées. Le client récupérait le fichier, recalculait l’empreinte indiquée et devait écarter les données en cas de différence. Une référence directe désignait les variantes une par une ; une référence indirecte menait à une structure décrivant plusieurs formats ou représentations. Des URI de secours pouvaient conduire au même objet.

Cette vérification est précise, mais son objet est limité : elle établit que le fichier téléchargé correspond aux octets référencés par le certificat. Elle ne démontre pas, à elle seule, que la marque représentée appartient réellement à l’organisation nommée, que l’émetteur avait le droit de l’utiliser ou que la personne la reconnaîtra correctement. Elle ne répare pas non plus un chemin de certification invalide. Identité des octets, validité du certificat et interprétation humaine restent trois choses distinctes. RFC 9399 a modernisé les règles de hachage ; l’obligation historique SHA-1 de RFC 3709 n’est pas un conseil cryptographique actuel. RFC 3709 §4.2 RFC 9399 §4.2

Pas de logo pour un certificat invalide

La frontière vaut aussi pour l’affichage. RFC 3709 interdit au logiciel de présenter le logotype d’un certificat qu’il n’a pas pu valider. Le signe visuel accompagne les autres informations d’identité ; il ne les remplace pas. Le texte avertit qu’un émetteur malhonnête ou négligent peut associer à un certificat un nom ou un dessin qu’il n’est pas en droit de revendiquer, et transformer ainsi la familiarité en outil d’ingénierie sociale.

La norme ne prétend pourtant pas que les images sont sans effet. Elle reconnaît qu’un logo peut peser dans la décision d’une personne de faire confiance à un certificat ou de l’utiliser. C’est justement pour cette raison qu’elle sépare la vérification automatique de la reconnaissance. La machine établit le résultat défini par sa politique de certification ; la personne peut ensuite tenir compte de l’identité affichée, du contexte et de l’usage prévu. Le logo contribue éventuellement à ce jugement, mais il ne devient pas une étape cryptographique. RFC 3709 §§1.3, 5–7

La limite a traversé les révisions

RFC 6170 a actualisé l’extension en 2011, puis RFC 9399 a remplacé les deux textes en 2023. Le successeur garde la distinction essentielle et ajoute un enjeu de confidentialité plus contemporain : récupérer un logo distant peut révéler quel certificat le client utilise. Avec TLS 1.3, cette requête peut dévoiler une identité de serveur que le certificat chiffré cherchait autrement à soustraire aux observateurs du réseau. La mise en cache déplace le moment de cette divulgation ; elle ne transforme pas l’image en preuve. RFC 6170 RFC 9399 §9

L’apport historique ne se résume donc pas à l’ajout de couleurs aux certificats. RFC 3709 a spécifié une aide à la reconnaissance, puis en a limité explicitement la portée probante : une image vérifiable par empreinte reste une information destinée aux personnes, pas un verdict implicite du moteur de validation.

Références