Résumé

  • RFC 9734 enregistre id-kp-imUri, l’OID 1.3.6.1.5.5.7.3.40, afin qu’un certificat puisse limiter sa clé à la signature d’identifiants de messagerie instantanée plutôt qu’à l’authentification TLS générale.
  • L’EKU décrit une finalité. L’URI du compte relève de subjectAltName ; la chaîne de certification, la comparaison avec l’identifiant attendu, le contrôle du compte, la révocation et l’autorisation applicative sont des décisions distinctes.
  • Dans MLS, la clé du certificat doit correspondre à la clé de signature du LeafNode. L’application doit néanmoins choisir les identifiants acceptables, et son service d’authentification doit encore effectuer la validation.

Imaginons une cellule de crise qui ouvre un groupe chiffré à un nouveau terminal. Le tableau de contrôle affiche trois succès : certificat signé, chaîne valide, id-kp-imUri présent. L’opérateur voit un nom de compte et clique sur « admettre ».

Le troisième succès ne justifie pas le clic.

RFC 9734, publié en février 2025, crée une finalité de clé spécialisée pour les certificats d’identité de clients de messagerie instantanée. La raison est saine : une organisation peut refuser qu’un certificat conçu pour la messagerie porte id-kp-clientAuth ou id-kp-serverAuth, car ces finalités générales agrandissent la surface d’une attaque interprotocole.

Le texte recommande précisément de ne pas combiner ces finalités larges avec id-kp-imUri. La valeur de la nouvelle extension tient à l’étroitesse du couloir. Mais un couloir ne choisit ni le voyageur ni sa destination.

Trois questions qu’un même certificat ne fusionne pas

RFC 5280 attribue deux fonctions différentes à deux extensions. Extended Key Usage indique les usages permis de la clé publique certifiée. Subject Alternative Name associe des identités au sujet ; une URI y est codée sous la forme uniformResourceIdentifier.

Ainsi, id-kp-imUri répond à une question de finalité. L’URI im: présenté dans subjectAltName répond à une question de nom. La construction d’une chaîne vers une ancre de confiance répond à une question de PKI. Aucun de ces résultats ne prouve automatiquement que le titulaire contrôle encore le compte, que ce téléphone est géré, ou que la politique du groupe autorise son admission.

RFC 3860 définit l’URI im: comme l’adresse d’une INSTANT INBOX. Il recommande, pour les opérations S/MIME de messagerie instantanée, d’inscrire l’URI du sujet dans subjectAltName. Le même document précise que son service abstrait suppose la fiabilité de la livraison et ne fournit pas lui-même d’assurance de livraison au niveau applicatif. Le nom, le transport et l’issue ne formaient déjà pas un seul verdict.

RFC 6121 montre un autre espace de noms possible, l’identifiant XMPP. Un JID peut désigner un compte ou une ressource, tandis que les changements de roster et le traitement des stanzas gardent leurs propres règles d’autorisation. Un identifiant correct n’est pas une délégation universelle.

Le registre donne un numéro, pas une attestation

Le registre SMI de l’IANA affecte le nombre 40 à id-kp-imUri sous l’arc PKIX. Cela garantit que les implémentations parlent de la même finalité. Le registre n’a vu ni la demande de certificat, ni le défi de compte, ni la politique de l’émetteur.

Le caractère critique ou non critique de l’extension relève de l’émetteur. Si une application exige cette finalité, elle doit réellement la contrôler. Un parc de certificats peut donc afficher une forte « adoption » sans produire de réduction de risque si les clients acceptent aussi une finalité absente, une finalité générale ou anyExtendedKeyUsage.

L’indicateur utile est négatif : combien de tentatives incorrectes ont été rejetées ? Présenter un certificat IM à un chemin TLS client ou serveur doit échouer selon la politique attendue. Présenter un certificat TLS général à l’admission IM doit également échouer lorsque le profil l’exige. La présence de l’OID n’a d’effet que dans le code qui refuse le mauvais usage.

Une chaîne valide ne connaît pas le compte attendu

La validation de chemin vérifie signatures, dates, contraintes, politiques, Key Usage et EKU selon des entrées données. Elle ne sait pas quel compte la personne ou le service voulait joindre.

RFC 9525 distingue, pour les identités de service, les identifiants présentés par le certificat et l’identifiant de référence construit par le client. Cette séparation devient directement opérationnelle dans MLS : le système doit conserver le nom attendu, les noms présentés, la règle de comparaison et le résultat.

Si un certificat contient deux URI, la chaîne peut rester valide. Si un alias a été renommé, le certificat peut rester cryptographiquement intact. Si un employé quitte une organisation, la signature de l’émetteur ne s’efface pas. Une interface qui ne garde que « certificat valide » a perdu la question d’identité avant même d’afficher sa réponse.

Dans MLS, l’application reprend la main

RFC 9420 exige, pour un X509Credential, que la clé publique du certificat d’entité finale corresponde à la signature_key du LeafNode. Ce lien empêche qu’un membre présente un certificat puis signe avec une clé sans rapport.

L’architecture ne s’arrête pas là. L’application choisit les identifiants de référence acceptables. Le service d’authentification vérifie que le credential représente légitimement ses identifiants présentés, puis qu’ils authentifient les identifiants attendus. Un nouveau credential doit être validé lors de l’ajout ou du remplacement prévu par le protocole.

Quatre reçus doivent donc rester lisibles : correspondance entre clé de certificat et LeafNode ; chemin et extensions acceptés ; URI présentée comparée à l’URI attendue ; admission de ce client dans ce groupe et cet epoch. L’EKU contribue au deuxième reçu, pas aux trois autres.

Le compte ne suffit pas non plus à identifier le terminal. Plusieurs appareils d’une même personne peuvent présenter la même identité applicative. Un index de feuille n’est stable que dans un epoch. Une politique qui distingue téléphone personnel, poste géré et robot doit conserver un identifiant de client ou de terminal distinct du compte.

La date d’émission n’est pas l’état présent

Un compte peut être suspendu après émission. Un appareil peut être perdu. Une clé peut rester disponible après la fin d’un mandat. Le certificat statique ne peut pas se réécrire.

RFC 6960 définit pour OCSP les états good, revoked et unknown. good signifie au minimum qu’aucun certificat correspondant, dans sa période de validité, n’est signalé révoqué ; ce n’est pas une attestation générale d’émission ni de validité. thisUpdate, nextUpdate et producedAt donnent une portée temporelle à la réponse.

Le brouillon d’architecture cité par RFC 9734, draft-barnes-mimi-identity-arch-02, traite la révocation comme un flux séparé et compare certificats courts, OCSP et listes de révocation. C’est un travail en cours, pas la preuve d’un déploiement. Sa leçon de composition est néanmoins nette : l’état actuel vient d’un système extérieur au certificat.

Le dossier que le voyant vert devrait résumer

À l’émission : URI demandée, méthode de preuve du compte, identité de l’autorité, version de politique, preuve de possession de clé, subjectAltName, EKU, numéro de série et intervalle de validité.

À la validation : identifiant attendu, identifiants présentés, règle de comparaison, chaîne, ancre, résultat EKU, date, source de révocation, fraîcheur et comportement en cas d’échec.

À l’admission MLS : empreinte du credential, clé du LeafNode, décision du service d’authentification, groupe, epoch, client, règle d’admission et décision de succession lors d’un remplacement.

Après l’action : proposition acceptée, message authentifié, remise au service de livraison, accusé du terminal ou résultat humain — mais uniquement si le système correspondant l’a observé.

Les versions canoniques texte et XML, la fiche RFC Editor, l’index des errata et l’historique IETF établissent la provenance du standard, non son déploiement.

La primauté du code en fonctionnement de Heng Lu demande quels contrôles sont réellement exécutés. Le principe de spécification initiale minimale justifie un OID commun étroit sans absorber les décisions locales de compte et d’admission. La discipline des couches de réalité empêche le numéro enregistré, l’extension, le nom comparé et l’autorisation d’être présentés comme un seul fait.

RFC 9734 améliore la confiance en réduisant la taille d’une affirmation. Le logiciel doit conserver cette modestie.

Sources