Résumé

  • La révision 01 de draft-tiloca-lake-private-use-ranges propose des plages d'usage privé pour trois registres EDHOC, avec des entiers CBOR codés sur cinq octets au total.
  • Les bornes 4294967295 et -4294967296 sont représentables par CBOR, mais pas par un entier signé sur 32 bits ; il faut donc préserver la valeur mathématique au-delà du décodage.
  • Une valeur d'usage privé n'a de sens qu'à l'intérieur d'un domaine de coordination explicite. L'authentification du message ne prouve ni l'accord sémantique des pairs ni l'effet de l'application.

La valeur la plus instructive du projet n'est pas un nouveau mécanisme cryptographique. C'est une limite numérique. Le document Additional Private Use Ranges in the IANA Registries of the Lightweight Authenticated Key Exchange Protocol réserve, entre autres, 65536 à 4294967295 et -4294967296 à -65537 à l'usage privé. Ces nombres conservent les petites plages existantes pour les usages publics et demandent un argument CBOR de quatre octets.

Avec l'octet initial, l'entier occupe cinq octets. Mais l'argument de quatre octets n'est pas un int32. RFC 8949 encode les entiers positifs avec le type majeur 0 et les négatifs avec le type majeur 1, où la valeur est -1-N. Ainsi, le même argument maximal 4294967295 peut représenter 4294967295 ou -4294967296. Les deux nombres débordent de l'intervalle signé 32 bits.

Le décodeur n'est que la première frontière

Une bibliothèque CBOR moderne peut retourner un entier 64 bits parfaitement correct. L'erreur peut survenir plus tard : conversion vers une énumération C, clé de table tronquée, sérialisation JSON imprécise, colonne de base de données trop étroite ou compteur de télémétrie signé. Dire « notre décodeur accepte le paquet » ne couvre aucune de ces frontières.

Il faut tester la valeur à chaque changement de représentation. La preuve utile contient les octets reçus, le type majeur, la largeur de l'argument, l'entier mathématique avant conversion et le résultat de chaque conversion contrôlée. Sans cela, un journal affichant -1 ne permet plus de savoir si le pair avait envoyé -1, 4294967295 ou une valeur déjà altérée par un composant intermédiaire.

Le signe EAD est une instruction de traitement

Pour les données d'autorisation externes, le signe ne peut pas être jeté après la recherche dans le registre. RFC 9528 enregistre la valeur absolue de ead_label, mais utilise un label négatif pour déclarer l'élément critique. 65536 et -65536 désignent donc le même type privé, tandis que la seconde forme impose un comportement plus strict au destinataire qui ne le comprend pas.

La paire révèle aussi une asymétrie d'encodage : 65536 exige cinq octets, alors que -65536 utilise l'argument 65535 et n'en exige que trois. Un test qui suppose que les formes positive et négative ont la même longueur manque précisément le changement de bord. Un code qui calcule d'abord une valeur absolue dans un type trop étroit peut perdre à la fois l'identifiant et la criticité.

Le reçu doit donc garder trois champs distincts : label signé reçu, clé absolue consultée dans le registre et décision de criticité. Leur fusion détruit l'explication de la décision.

Privé ne veut pas dire unique

RFC 8126 définit l'usage privé comme un espace où l'interopérabilité générale n'est pas attendue et où plusieurs acteurs peuvent employer la même valeur différemment. Le projet reprend cette logique : chaque déploiement prévient les collisions dans son périmètre, sans prétendre coordonner l'ensemble d'Internet.

Cette liberté fonctionne tant que le périmètre est nommé. Deux fabricants peuvent choisir le code 70000 pour deux méthodes différentes. Chacun est cohérent chez lui. Un concentrateur commun, une acquisition ou un composant réutilisé peut les mettre en présence. Le nombre seul ne suffit plus ; il faut l'identifiant du domaine privé, la version du profil et la règle de refus lorsque le pair n'appartient pas au même ensemble de compatibilité.

Trois registres, trois décisions

Les types de méthode déterminent une construction d'authentification. Les codes d'erreur orientent l'interprétation d'un échec. Les labels EAD sélectionnent des données opaques pour EDHOC et ajoutent la criticité par le signe. Un même défaut de représentation peut donc provoquer un rejet propre, un mauvais diagnostic ou la sélection d'un gestionnaire local erroné.

Cela ne prouve pas une faiblesse d'EDHOC. La révision 01 indique que les considérations de sécurité de RFC 9528 restent applicables. Elle n'annonce aucun incident ni implémentation défaillante. Elle rend seulement impossible une excuse fréquente : croire que la validité du fil garantit la validité de l'objet logiciel.

Une matrice de tests aux vraies bornes

Les valeurs 65535, 65536, 4294967295, -65536, -65537 et -4294967296 doivent toutes apparaître dans les vecteurs. Ajoutons les valeurs juste hors plage, les formes EAD critiques et non critiques, puis deux profils privés qui attribuent volontairement des sens incompatibles au même nombre. Les assertions portent sur l'entier décodé, la conversion, le gestionnaire, la criticité, le journal et le refus de compatibilité—notamment pas seulement sur la réussite de la poignée de main.

Le registre IANA EDHOC capturé aujourd'hui décrit l'état courant établi par RFC 9528. Le Datatracker classe la révision 01 comme Internet-Draft individuel. La demande n'est donc ni une allocation déjà réalisée, ni une preuve de déploiement. Même l'existence de plages privées voisines dans RFC 9668 ne prouve pas que les chemins de code visés ici préservent ces bornes.

Le reçu minimal

Un reçu d'extension privée devrait conserver le registre concerné, les octets CBOR originaux, la valeur mathématique, les conversions contrôlées, le triplet EAD signe/valeur absolue/criticité, le domaine privé et sa version, le profil annoncé par chaque pair, le gestionnaire choisi, la référence au transcript authentifié et le résultat d'application. Ce reçu ne rend pas la valeur mondiale, ne publie pas nécessairement sa sémantique propriétaire et ne transforme pas un traitement local en standard.

Sources