Résumé

  • draft-ietf-cose-cbor-encoded-cert-21 définit un C509 réversible vers le DER signé et un C509 signé directement sur le CBOR.
  • Décodage et signature valides ne suffisent pas : la validation de chemin RFC 5280 demeure obligatoire et les certificats transportés par COSE restent des entrées non fiables.
  • Un code IANA nomme un objet ou un algorithme ; il ne le recommande pas et ne l’autorise pas localement.

Le vérificateur doit savoir quels octets ont été signés

Le type 3 compresse un certificat X.509 DER de manière inversible. Le destinataire reconstruit le DER original et vérifie la signature historique. Le type 2 signe nativement le groupe CBOR TBSCertificate. Les deux portent la sémantique X.509, mais ils ne produisent pas le même reçu : dans un cas, il faut conserver le DER reconstruit ; dans l’autre, les octets CBOR canoniques.

Le gain provient d’une connaissance du modèle : champs statiques supprimés, OID remplacés par de petits entiers, temps et certains points elliptiques raccourcis. Ce résultat concerne la représentation. Il ne prouve ni la possession actuelle de la clé privée, ni l’autorité de l’émetteur pour l’usage demandé, ni l’actualité du certificat, ni la permission d’exécuter une opération.

Le projet le dit sans détour : les hypothèses de sécurité de X.509 ne changent pas. Avant de déclarer le certificat fiable, il faut toujours exécuter la validation de chemin de la section 6 de RFC 5280. Cette étape examine ancres, contraintes, dates, politiques, noms, extensions critiques et usage. Une signature verte n’est qu’une pièce de cette décision.

COSE transporte un candidat, pas une nouvelle racine

Les paramètres c5b, c5c, c5t et c5u peuvent apporter des certificats ou des références. Leur contenu demeure non fiable. La présence d’un certificat auto-signé ne doit jamais modifier automatiquement les ancres locales. Même un en-tête COSE protégé authentifie l’enveloppe ; il ne délègue pas à son contenu le pouvoir de choisir les racines.

C509 ajoute aussi des types de média, formats CoAP, un type de certificat TLS et un sélecteur TLSA. Ils rendent le format reconnaissable. Ils ne remplacent ni DNSSEC et les règles DANE, ni l’identité du service, ni la politique applicative.

Les registres C509 illustrent la même séparation. La spécification précise qu’un enregistrement IANA n’est pas une recommandation ; des algorithmes obsolètes obtiennent parfois un code uniquement pour représenter des certificats existants. Le registre TLS affiche actuellement C509 Certificate, valeur 4, avec Recommended = N. Ce « N » ne condamne pas le format. Il indique que le registre n’accorde pas une recommandation générale. La signification du numéro, l’état du consensus et la politique locale sont trois choses différentes.

Les tableaux de taille ne sont pas des résultats de production

Dans les exemples du projet, C509 réduit fortement certains certificats IoT profilés. Brotli peut en plus exploiter les répétitions d’une chaîne entière. Pour FN-DSA et ML-DSA, clés publiques et signatures dominent ; presque aléatoires, elles se compressent peu. Il serait donc faux de transformer une moyenne en promesse universelle d’énergie, de latence ou de fiabilité.

Une passerelle peut convertir C509 en X.509 afin de préserver un serveur ancien. Le projet avertit que ce modèle exige des certificats non chiffrés et peut violer la protection d’identité. Quand le protocole chiffre les certificats de bout en bout, les extrémités doivent comprendre C509. La fidélité de conversion, la sûreté du parseur et la confiance restent des contrôles séparés.

La révision 21 date du 24 septembre 2026. Elle est approuvée par l’IESG, dans la file du RFC Editor et bloquée dans l’attente d’une réponse des auteurs. C’est un état de publication, non un rejet technique, un numéro de RFC ou une preuve de déploiement.

Sources