Résumé

  • L’appel HTTPbis porte sur l’adoption possible de draft-hardt-httpbis-signature-key-08; selon le Datatracker, un appel en cours ne signifie pas que le groupe a atteint un consensus d’adoption.
  • Les en-têtes proposés peuvent aider un vérificateur à obtenir une clé publique. Ils ne désignent ni le titulaire d’une politique locale, ni l’usage auquel un signataire est autorisé, ni la délégation dont dépend une opération.

La difficulté vient souvent d’un raccourci séduisant. Un serveur reçoit une requête signée. Il trouve une clé grâce à un en-tête ou à une référence. La signature se vérifie. Le raccourci conclut alors que la requête est digne de confiance au sens complet. Mais chaque verbe de cette phrase désigne un contrôle différent. Trouver une clé est une opération de découverte. Vérifier une signature est une opération cryptographique. Accorder une action est une décision de politique prise par le propriétaire d’une ressource.

L’appel public d’HTTPbis ne masque pas le premier niveau. Il demande à la liste si draft-hardt-httpbis-signature-key-08 doit être adopté comme travail du groupe et demande des avis motivés avant le 7 septembre 2026. Le texte décrit cinq en-têtes HTTP associés aux HTTP Message Signatures et huit premiers modes de distribution ou de découverte : clé en ligne pseudonyme, délégation liée à une empreinte JWK, URI de JWKS, JWKS direct, formes JWT, certificat X.509 et assertion mise en cache.

Cette énumération expose une surface technique sérieuse. Elle ne sélectionne pas un modèle de confiance. Le Datatracker distingue expressément l’état « Call For Adoption By WG Issued » d’un résultat : l’appel est encore en cours et le groupe n’a pas atteint le consensus nécessaire à l’adoption. Une appréciation ultérieure des chairs, un document de groupe, une revue, une action de l’IESG et une publication RFC seraient des actes ultérieurs, chacun attribuable à son moment et à son instance. La date de clôture ne contient pas ces étapes à l’avance.

Le projet mérite une lecture attentive parce que ses mécanismes ont des conséquences diverses. Une clé en ligne peut favoriser un fonctionnement pseudonyme. Une URI de JWKS peut conduire le vérificateur à aller chercher un document externe. Une chaîne X.509 peut relier la validation à une infrastructure de certificats. Un JWT peut porter une forme de délégation. Le serveur peut annoncer les schémas et algorithmes qu’il accepte afin que le client fasse un choix avant de signer. Les choix de cache, de récupération, de protection contre les requêtes indésirables et de prise en charge des algorithmes peuvent tous affecter une implantation réelle.

Ils ne répondent pourtant pas à la question de l’autorité. Une signature valide peut montrer que le détenteur de la clé privée correspond à un matériel public obtenu selon une procédure donnée. Elle ne dit pas si ce détenteur représente un client inscrit, un agent d’entreprise, un employé, un partenaire, un processus éphémère ou un tiers non admis. Elle ne dit pas s’il agit pour son propre compte ou par délégation, quel plafond lui est accordé, quelle décision exige un second contrôle, ni quelle information un auditeur doit garder si la requête est contestée.

Le texte de Signature-Key ne cherche pas à effacer cette séparation. Il indique que les clés préconfigurées et les échanges hors bande sortent de son champ. L’en-tête n’est pas obligatoire pour de telles signatures, et le vérificateur peut obtenir une clé par des moyens propres à l’application. Cette phrase maintient une liberté de déploiement importante. Un service peut employer l’en-tête, le compléter par une relation de compte, imposer un registre d’émetteurs, ou préférer entièrement un autre moyen de distribution.

Pour cette raison, la proposition ne peut être décrite comme la décision d’un propriétaire de ressource. Prenons un système qui libère un paiement, modifie un dossier confidentiel, lance une charge de calcul ou donne à un agent accès à un outil. Même si le message est correctement signé et même si la clé est trouvée par l’un des schémas proposés, les éléments qui rendent l’action acceptable restent locaux : identité pertinente, lien de délégation, politique applicable, finalité, durée, périmètre, règles de refus, journal, recours et révocation. Aucun champ HTTP générique ne transfère ces choix à HTTPbis.

Le mandat du groupe éclaire aussi cette limite. HTTPbis maintient le cœur de HTTP et peut élaborer des extensions génériques, non propres à une application. Il réunit des personnes qui travaillent sur l’interopérabilité, l’exploitation et l’évolution du protocole. Cette compétence est réelle. Elle ne transforme pas le groupe en arbitre des droits d’un utilisateur dans un service de santé, des pouvoirs d’un logiciel de trésorerie ou des engagements contractuels d’une place de marché. Les chairs conduisent une procédure de groupe; ils ne deviennent pas administrateurs de chaque politique d’accès qui pourrait utiliser HTTP.

Il serait donc faux de conclure que le projet est sans intérêt. Une interface commune pour transporter ou référencer de la matière de vérification peut réduire des arrangements bilatéraux et rendre les implémentations plus lisibles. L’éventail de schémas donne précisément au groupe des questions utiles à examiner : quelles combinaisons sont interopérables, quels risques de substitution ou de récupération apparaissent, quelles annonces doivent être couvertes par une signature et quels enregistrements méritent une discipline commune.

Mais l’interopérabilité n’est pas une procuration. Un fournisseur ne peut pas présenter la prise en charge de Signature-Key comme preuve qu’il est autorisé à agir pour son client. Un chemin X.509 ne suffit pas à démontrer un rôle métier. Un intégrateur ne peut pas laisser un texte de standard absorber ses choix sur la récupération de JWKS, la liaison entre identité et compte, le traitement des délégations ou la conservation des traces. Le mécanisme peut soutenir une décision locale; il n’en est pas le titulaire.

Un registre de preuve simple évite cette confusion. La colonne protocolaire conserve l’appel, la version du draft, les futurs actes de consensus et les contraintes techniques adoptées. La colonne applicative conserve le propriétaire de la politique, les catégories de signataires acceptées, les règles de récupération, les preuves de délégation, les limites, les refus, les journaux et la révocation. Une application peut relier les deux colonnes. Elle ne peut pas traiter la première comme si elle avait déjà rempli la seconde.

L’état actuel permet donc une conclusion sobre. HTTPbis discute l’adoption éventuelle d’un mécanisme générique de clés de signature. Il n’a pas adopté le document, choisi une politique de confiance universelle, nommé l’émetteur qu’une application doit accepter ou autorisé une opération concrète. Préserver ces frontières rend à la fois le débat technique et la responsabilité applicative plus vérifiables.

Sources