Résumé

  • Dans COSE, kid est une donnée non structurée et non unique qui aide à retrouver des clés candidates ; il ne constitue ni une empreinte, ni une identité, ni une autorisation.
  • Une vérification explicable doit conserver le domaine de recherche, toutes les clés candidates, l’empreinte de celle qui a validé la signature, les octets couverts, le lien d’identité, la politique applicable et l’effet observé.

Prenons deux coffres logiques. Chacun contient une clé portant l’étiquette courte 0x19. Le premier appartient à une rotation encore ouverte ; le second à un autre espace client. Un message arrive avec cette étiquette dans son en-tête non protégé. Le vérificateur essaie les clés et l’une d’elles valide la signature.

La collision n’enfreint pas la règle. C’est le compte rendu « l’identité 0x19 a signé » qui devient faux. Il remplace une recherche à plusieurs réponses par un nom unique que le protocole n’a jamais fourni.

Ce scénario n’est pas un incident réel. Il sert à lire une décision de conception de COSE : garder un raccourci utile sans lui attribuer le pouvoir de conclure.

Une étiquette qui réduit la liste

La RFC 9052 attribue à kid le numéro de paramètre 4 et le type chaîne d’octets. Le champ peut être rapproché du membre kid d’un objet COSE_Key ou d’une donnée équivalente définie par une autre méthode de distribution. Sa fonction est de fournir une entrée à la recherche de la clé nécessaire.

Le texte écarte ensuite toute unicité implicite. Plusieurs clés peuvent porter la même valeur et il peut être nécessaire de toutes les tester. La structure interne de la valeur n’est pas définie. Dans COSE_Key, elle peut avoir été choisie par un utilisateur ou calculée à partir de la partie publique de la clé ; elle peut néanmoins réapparaître dans un objet correspondant à une autre clé.

L’opération correcte produit donc un ensemble, pas un sujet. Elle part d’un contexte d’application, d’un tenant ou d’un émetteur, d’une version du magasin et d’un instant. Elle restitue zéro, une ou plusieurs clés candidates. La signature détermine ensuite si l’une de ces clés fonctionne avec les données reçues.

Le registre COSE de l’IANA conserve cette définition minimale : kid, étiquette 4, chaîne binaire, identifiant de clé. Il enregistre aussi séparément kid context. Ce second paramètre n’est pas obligatoire partout ; sa présence montre toutefois que le périmètre d’un identifiant court est un fait distinct de ses octets.

Non protégé ne signifie pas digne de confiance

Les structures COSE comportent un compartiment protégé et un compartiment non protégé. Le premier alimente la construction authentifiée. Le second transporte des paramètres qui peuvent être utiles sans recevoir cette propriété. La RFC exige notamment de protéger l’algorithme lorsque la construction le permet.

Pour kid, le raisonnement est inverse : la RFC le qualifie d’indice, non de champ critique pour la sécurité, et autorise son placement dans l’en-tête non protégé. La sécurité ne doit donc jamais dépendre de la vérité de cette étiquette.

Une modification peut néanmoins avoir un coût. Elle peut agrandir la recherche, solliciter un mauvais magasin, traverser un tenant mal isolé ou rendre la journalisation trompeuse. Elle ne crée pas, à elle seule, une signature valide avec une clé étrangère. Le contrôle cryptographique doit encore réussir avec une clé réelle. L’architecture raisonnable borne les recherches, cloisonne les domaines et garde la trace des essais au lieu de faire de l’indice un verdict.

Le sujet exact de la signature

COSE ne vérifie pas une ligne d’interface. Pour une signature, la RFC 9052 construit Sig_structure avec le contexte de signature, les paramètres protégés du corps, les paramètres protégés du signataire lorsqu’ils existent, les données authentifiées fournies par l’application et la charge utile complète. L’encodage de cet ensemble produit les octets ToBeSigned remis à l’algorithme avec la clé et la signature.

Un reçu technique devrait donc préserver le type de structure, les octets bruts des en-têtes protégés, la recette des données externes et le hachage de la charge utile telle qu’elle a été traitée. Il devrait consigner chaque empreinte de clé candidate, son origine, le résultat de l’essai et la cause d’un rejet antérieur à la cryptographie, par exemple un paramètre critique inconnu.

Cette granularité empêche une interface de colorer tout le message en vert. Si kid se trouve dans la partie non protégée, sa proximité visuelle avec une coche de signature ne l’intègre pas rétroactivement aux octets signés.

Deux contrôles commencent après le calcul

La procédure de la RFC 9052 ne s’arrête pas lorsque l’équation cryptographique est vraie. Elle demande à l’application de vérifier que la clé est correctement associée à l’identité du signataire, puis que cette identité est autorisée avant d’exécuter une action.

L’association peut venir d’un certificat, d’un reçu de provisionnement, d’une attestation matérielle ou d’un registre local gouverné. L’autorisation vient d’une autre source : rôle, ressource, finalité, période, version de politique. Une clé peut rester capable de valider un ancien message alors que son détenteur n’a plus le droit d’émettre une nouvelle commande. Deux clés de rotation peuvent partager un indice pendant une période de grâce sans partager la même période d’autorité.

Il faut aussi séparer les horloges. Le magasin a une version au moment de la recherche ; le lien d’identité possède un intervalle de validité ; la politique est évaluée à un instant ; l’application peut confirmer ou refuser l’effet plus tard. Une seule colonne « validé » ne peut représenter cette chronologie.

Le profil d’application donne la juridiction

La section 10 de la RFC 9052 explique que COSE fournit des services et des structures, tandis que chaque application choisit les messages, paramètres, algorithmes et méthodes de négociation nécessaires. Cette latitude ne permet pas au vérificateur d’inventer des règles. Elle exige qu’un profil nomme celles qu’il applique.

La RFC 9200, consacrée à ACE OAuth, donne un cas parlant. Dans une réponse du serveur d’autorisation comportant une clé de preuve de possession, kid ne sert qu’à simplifier l’indexation et la récupération. Son unicité ne doit être supposée ni dans le domaine du client ni dans celui du Resource Server. Même au cœur d’un flux d’autorisation, l’identifiant court ne porte pas l’autorisation.

Le reçu doit alors nommer le profil et sa version, l’émetteur ou serveur d’autorisation, le client ou Resource Server, le domaine de recherche, les usages admis de la clé et la décision de politique. Sans ces éléments, un succès cryptographique demeure incomplet.

La contribution de Schaad ne remplace pas le consensus

Jim Schaad est l’auteur de la RFC 8152, première spécification COSE publiée en 2017. La RFC 9052, dont le cartouche porte également J. Schaad, en a remplacé la partie structures et processus, les algorithmes étant séparés dans la RFC 9053. Le profil Datatracker de Jim Schaad relie cette contribution à un ensemble plus large de RFC.

Ces documents expriment un consensus de l’IETF. Ils ne donnent à leur auteur ni la maîtrise d’une implémentation, ni le pouvoir de certifier un déploiement. Un article commémoratif d’Oregon Wine Press fournit la photographie créditée utilisée comme référence d’identité pour l’illustration éditoriale ; cette image n’est pas une preuve technique.

Conserver les candidats perdants

Le journal utile part de l’objet reçu. Il enregistre son empreinte, la structure COSE, les en-têtes protégés et non protégés, les données externes et la charge utile. La recherche devient un objet séparé contenant le domaine, la version du magasin, l’heure, le kid reçu et la liste entière des résultats.

Chaque candidat garde une empreinte complète, une provenance, des usages et un résultat. La clé victorieuse pointe vers un reçu de vérification portant le hachage exact de ToBeSigned. Le lien d’identité et la décision d’autorisation sont ajoutés ensuite, sans être fusionnés. L’engagement applicatif et son observation ferment la chaîne.

Les échecs expliquent les changements d’ordre, les fenêtres de rotation et les différences entre nœuds. Les supprimer revient à écrire après coup que l’indice a toujours désigné la bonne clé. Les garder permet une conclusion beaucoup plus modeste et beaucoup plus solide : telle clé a validé tels octets ; telle preuve l’a reliée à telle identité ; telle politique a permis ou refusé l’action ; tel résultat a été observé.

Sources