Résumé

  • Dans RFC 9688, les identifiants de digest, ECDSA, HMAC et HKDF avec SHA3 exigent des paramètres absents, les signatures RSA PKCS#1 v1.5 avec SHA3 exigent NULL, et KMAC exige soit l’absence, soit la valeur exacte de personnalisation.
  • Une validation réussie ne prouve ni la conservation des octets reçus, ni la conformité du réencodage, ni la validité de la chaîne de certificats, ni l’autorité du signataire, ni le résultat de l’application.

Le cas révélateur n’est pas nécessairement une attaque. C’est une archive qui veut rendre les objets homogènes. Elle reçoit un SignedData, vérifie la signature, transforme l’ASN.1 en structure interne puis sauvegarde une nouvelle sérialisation. Son interface conserve le même OID. Pourtant, si elle retire le NULL obligatoire d’un identifiant RSA-with-SHA3, elle ne conserve pas le même contrat.

Ce scénario n’accuse aucun produit nommé. Il sert à montrer qu’un OID est une coordonnée, pas un reçu complet. Le reçu complet doit nommer le champ CMS, la forme des paramètres, les identifiants imbriqués, les octets exacts, la clé, l’implémentation, la politique et la décision en aval.

Une matrice, pas une préférence de style

Pour SHA3-224, SHA3-256, SHA3-384 et SHA3-512 utilisés comme digest, les paramètres doivent être absents. La règle vaut dans les champs de digest de SignedData, SignerInfo, DigestedData et AuthenticatedData. « Absent » ne signifie pas « présent et égal à NULL ».

Les signatures ECDSA avec SHA3 suivent la même règle d’absence. Les MAC HMAC-SHA3 également. Les identifiants HKDF-with-SHA3 aussi. Un encodeur générique qui ajoute systématiquement NULL produit donc un objet dont le nom paraît correct mais dont la représentation viole la convention applicable.

La branche RSA PKCS#1 v1.5 inverse la règle. Pour rsaEncryption et les quatre identifiants de signature RSA-with-SHA3, le champ doit contenir NULL. Une bibliothèque qui efface tous les NULL « inutiles » casse cette branche au nom d’une uniformité inexistante.

KMAC ajoute un troisième état. Sans étiquette de personnalisation S, les paramètres de KMAC128-KDF ou KMAC256-KDF doivent être absents. Avec S, ils doivent être présents et porter exactement cette chaîne d’octets. Une personnalisation vide présente n’est pas simplement une autre manière d’écrire l’absence. L’encodage fait partie de l’entrée attestée.

La spécification commune est donc petite mais stricte. La décision d’autoriser un algorithme peut rester locale. La forme reçue ne peut pas être redéfinie localement sans laisser une trace de transformation.

Le KDF possède des entrées que le journal ne montre pas

KMAC est défini ici par K, X, L et S. K est la clé de dérivation, souvent issue d’une décapsulation KEM. X est le contexte, qui comprend avec RFC 9629 le DER de CMSORIforKEMOtherInfo. L est la longueur de sortie. S est la personnalisation optionnelle.

Un journal qui écrit seulement id-kmac128 ne permet pas de reproduire le résultat. Il faut connaître le contexte exact, la longueur demandée et la personnalisation. Deux côtés peuvent reconnaître le même OID et dériver des clés différentes parce qu’ils n’ont pas assemblé les mêmes octets.

KDF2 et KDF3 contiennent en plus un identifiant de digest imbriqué. Si celui-ci sélectionne SHA3, ses paramètres doivent être absents conformément à la section 2. Contrôler l’OID externe sans inspecter l’identifiant interne revient à certifier une enveloppe sans lire son contrat.

Conserver l’original avant de le rendre pratique

Un parseur peut accepter plusieurs formes, les réduire à une seule valeur interne et perdre l’information sur la forme reçue. Il peut ensuite réémettre sa forme favorite. La réussite du parseur n’est donc pas un reçu de fidélité.

Une chaîne de preuve utile conserve : le hachage des octets CMS reçus ; le chemin du champ et l’OID ; l’état des paramètres et le hachage de leurs octets ; les identifiants imbriqués ; la version du parseur ; la présence d’une normalisation ; l’implémentation cryptographique ; la référence de clé ; le résultat cryptographique ; puis, séparément, la politique de certificat, l’autorisation et le résultat applicatif.

Même une signature valide reste bornée. Elle établit une relation cryptographique entre des octets, une signature et une clé. Elle ne prouve pas seule l’identité autorisée, la fraîcheur, le sens métier du contenu ni l’exécution de l’ordre signé.

Le registre ne peut pas voir le code qui tourne

IANA fournit les coordonnées nécessaires pour les identifiants HKDF-with-SHA3 et le module ASN.1. Cette coordination évite que deux mécanismes revendiquent le même nom. Elle ne constitue pas une enquête de déploiement. Elle ne dit pas qu’une bibliothèque encode les paramètres correctement, utilise le bon fournisseur ou interopère.

La clarté vient de la séparation : le registre prouve l’attribution du symbole ; les captures, vecteurs et traces prouvent le comportement ; l’application prouve son propre résultat. Réunir ces reçus est possible. Les confondre ne l’est pas.

Sources