Résumé

  • L’identifiant de clé OpenPGP est un sélecteur de 64 bits susceptible d’entrer en collision ; il ne désigne pas à lui seul un paquet de clé publique unique.
  • Une vérification défendable conserve les candidats, l’empreinte complète, la provenance, les certifications, l’état de validité, le résultat cryptographique et la décision d’autorisation.

Dans un annuaire de clés, la première réponse paraît souvent définitive. L’utilisateur saisit un identifiant court, une fiche apparaît, le nom attendu est visible et le bouton « vérifier » devient vert. Cette chaîne fabrique une impression d’unicité que le format n’a jamais garantie.

Le problème ne vient pas d’un identifiant mal conçu. Un repère court est utile pour rechercher, afficher et transporter une indication sur l’émetteur. L’erreur consiste à lui faire porter la clé entière, son propriétaire humain, son état présent et le droit d’agir.

Jon Callas est lié à cette frontière par l’histoire du standard. Son profil IETF recense cinq RFC, dont les RFC 2440 et 4880. Une biographie de l’ACLU, datée dans son contexte, retrace des fonctions dans la cryptographie et le logiciel. Ces sources établissent une contribution et un parcours, pas un emploi actuel. La RFC 9580, qui remplace la RFC 4880, a d’autres auteurs.

Huit octets pour retrouver des candidats

La RFC 4880 définit l’identifiant sur huit octets et demande explicitement de ne pas présumer son unicité. Pour une clé RSA de version 3, il provient des 64 bits de poids faible du module. Pour une clé de version 4, il reprend les 64 bits de poids faible de l’empreinte.

La RFC 9580 conserve ces huit octets et le même avertissement. Une clé de version 4 utilise toujours la partie basse de son empreinte SHA-1 ; une clé de version 6 utilise la partie haute d’une empreinte SHA-256. Le libellé « Key ID » masque donc aussi une différence de génération.

Une collision signifie que plusieurs paquets peuvent partager le sélecteur. Elle ne prouve ni attaque ni rupture de l’algorithme à clé publique. Le risque opérationnel apparaît quand un logiciel choisit silencieusement la première entrée, écrase les autres ou enregistre seulement le sélecteur. Deux dépôts peuvent alors rendre deux décisions avec le même identifiant apparent.

La version doit accompagner la preuve. Un même matériau RSA placé dans des paquets de versions 3, 4 et 6 peut produire des empreintes et des identifiants différents. L’identifiant court n’est pas le nom intemporel de la clé mathématique.

L’empreinte fixe le paquet, pas la biographie

L’empreinte complète réduit radicalement l’ambiguïté sur le paquet public sérialisé. Elle doit être calculée localement et comparée mécaniquement à une valeur attendue. La RFC 9580 se montre réservée sur la comparaison humaine de longues empreintes : la réponse n’est pas de revenir au repère court, mais d’authentifier le canal qui transporte l’empreinte.

Il faut donc conserver l’origine de la valeur attendue. Est-elle venue d’une configuration maîtrisée, d’un annuaire signé, d’un échange indépendant ou d’une page modifiable par n’importe qui ? Sans cette provenance, l’égalité des empreintes peut être exacte tout en comparant la mauvaise référence.

L’identité humaine reste encore à établir. Un paquet User ID contient du texte UTF-8 destiné à nommer une personne ou une organisation, souvent sous la forme d’un nom et d’une adresse électronique. Le format ne contrôle pas la vérité de ce texte. Les signatures de certification expriment un lien, avec des niveaux différents : la certification générique ne dit rien du soin apporté à la vérification ; la certification persona n’affirme aucune vérification ; les niveaux casual et positive annoncent des contrôles plus forts.

Afficher le bon nom à côté de la bonne empreinte n’établit donc ni contrat de travail, ni mandat, ni rôle actuel. Le système de confiance doit dire quels certificateurs sont acceptés, pour quel usage et à quelle date.

Une signature valide reste une réponse étroite

Dans une signature, le sous-paquet Issuer Key ID fournit encore un indice de huit octets. La RFC 9580 interdit cet indice pour les clés postérieures à la version 4 et recommande l’Issuer Fingerprint. Lorsque les deux coexistent pour une clé de version 4, les 64 bits attendus doivent correspondre. Cette cohérence aide à détecter une sélection incohérente ; elle ne remplace pas l’examen du paquet résolu.

La vérification cryptographique répond ensuite à une question bornée : cette signature est-elle valide avec cette clé pour ces octets précis ? L’expiration, la révocation, les algorithmes acceptés, l’instant pertinent et les key flags sont des contrôles séparés. Une clé capable de signer n’est pas forcément autorisée à approuver cette opération.

Enfin, le pouvoir organisationnel ne naît pas du calcul. Une signature valide sur un manifeste ne prouve pas que le signataire dirige la mise en production, que le manifeste décrit le bon artefact ou que la politique autorise le déploiement. Possession de la clé, identité certifiée, rôle présent et autorisation doivent se rejoindre par des preuves distinctes.

Construire un reçu sans effacer l’ambiguïté

Le reçu commence par les octets signés et le paquet de signature exacts. Il garde l’identifiant d’émetteur comme indice, énumère tous les candidats fournis par chaque dépôt et archive, pour le candidat choisi, le paquet public, sa version et l’empreinte complète recalculée. Il note le lieu et l’heure de récupération.

Puis viennent les champs que la recherche ne remplit pas : User ID examiné, chaîne de certification ou règle de confiance, expiration et révocation au moment pertinent, key flags, politique d’algorithme et résultat de vérification. Une décision d’autorisation explicite clôt le reçu ; elle ne doit pas être déduite du voyant vert précédent.

Si deux clés partagent l’identifiant, les deux restent visibles. Si le canal de l’empreinte est faible, cette faiblesse reste inscrite. Si personne n’a prouvé le rôle du signataire, le champ demeure vide. C’est cette fidélité aux limites de chaque preuve qui rend la décision reproductible.

Sources