Résumé

  • RFC 9690 précise que l’identifiant rsaEncryption d’un certificat n’annonce pas l’acceptation de RSA-KEM ; la volonté du destinataire est une preuve distincte.
  • Une décision reproductible doit relier le certificat, la date et l’origine de la capacité, les deux KDF, la longueur de KEK, l’algorithme de wrap et le type de contenu CMS.

Le piège ne se trouve pas dans une opération RSA obscure. Il apparaît plus tôt, dans l’inventaire. Une fiche indique « clé RSA, chaîne valide, taille autorisée ». Un moteur de composition traduit cette fiche en « destinataire RSA-KEM ». Or RFC 9690 dit expressément que rsaEncryption ne signale pas que le destinataire acceptera RSA-KEM avec cette clé.

Le certificat décrit un matériau cryptographique et les déclarations de son émetteur. L’acceptation dépend aussi d’un logiciel, d’une configuration, d’une politique et d’un instant. La clé peut rester valide alors que le chemin RSA-KEM a été désactivé, que le destinataire n’accepte plus ce type CMS ou qu’il n’autorise qu’une autre combinaison de composants.

Cette combinaison compte. RSA-KEM chiffre un entier aléatoire frais z avec la clé publique, puis une première KDF en tire un secret partagé. Le traitement CMS applique ensuite une autre KDF à ce secret pour obtenir la clé de chiffrement de clé. RFC 9690 autorise ces deux KDF à être différentes. KDF3 avec SHA-256 et AES-Wrap-128 constituent le minimum obligatoire, non la description complète de chaque mise en œuvre.

Une annonce de capacité n’est pas une propriété éternelle

Le destinataire peut publier sa volonté dans un attribut SMIMECapabilities d’un contenu signed-data selon RFC 8551, ou dans l’extension de certificat de RFC 4262. Cette preuve vaut mieux qu’une déduction à partir de la forme de la clé. Elle reste bornée : RFC 8551 parle d’une liste partielle, et un message signé ancien décrit une capacité annoncée à la date de ce message.

Il faut donc conserver qui a signé, quand, avec quel certificat, depuis quel canal et pour quelle combinaison. L’absence d’une entrée ne prouve pas automatiquement l’incapacité ; sa présence ne prouve pas que le service demeure activé ni que l’organisation autorise ce message précis.

Pour une clé exclusivement destinée à RSA-KEM, id-rsa-kem-spki porte une intention plus étroite. Sans paramètres, KDF3/SHA-256 s’applique à la dérivation interne. Avec paramètres, GenericHybridParameters impose la KDF, la longueur de KEK et le wrap utilisables dans KEMRecipientInfo. Si keyUsage existe, seule la valeur keyEncipherment est admise. Cela circonscrit l’usage ; cela ne produit ni la clé privée, ni un reçu de décapsulation.

La compatibilité avec RFC 5990 doit rester visible

RFC 5990 utilisait KeyTransRecipientInfo et concaténait le ciphertext C et la clé enveloppée WK. RFC 9690 adopte le KEMRecipientInfo générique de RFC 9629 : kemct et encryptedKey deviennent deux champs distincts. Une compatibilité descendante est permise, et certaines définitions ASN.1 gardent les mêmes bits sur le fil.

Mais une migration n’efface pas le choix. Le journal doit dire si le message suit RFC 5990 ou RFC 9690, quel certificat a servi, quelle capacité a motivé la sélection et quels paramètres la limitaient. Des opérations RSA identiques ne donnent pas le même conteneur, la même négociation ni le même diagnostic.

Un reçu utile sépare aussi les étapes côté destinataire : contrôle de longueur et de plage du ciphertext, opération avec la clé privée, dérivation du secret, dérivation de la KEK, unwrap, authentification ou déchiffrement du contenu, puis acceptation applicative. La construction réussie chez l’émetteur ne vaut pas exécution chez le destinataire.

Construire un reçu qui sait expirer

Pour chaque décision, l’émetteur devrait conserver l’empreinte du certificat, la validation de chaîne, l’AlgorithmIdentifier et ses octets de paramètres, keyUsage, la provenance et l’âge de l’annonce, la KDF interne, la KDF CMS, la longueur de KEK, le wrap, le type de contenu et la voie RFC 5990 ou RFC 9690 choisie.

Une rotation de certificat, une mise à jour du client, la désactivation d’un algorithme, un changement de contenu ou le premier échec propre à la combinaison doivent invalider le cache. Face à l’incertitude, le système confirme ou choisit un mécanisme autorisé séparément ; il ne transforme pas rsaEncryption en consentement implicite.

RFC 8017, RFC 3394, RFC 4086 et RFC 5280 définissent des frontières essentielles de représentation, de wrap, d’aléa et de certificat. Aucune ne constate l’état vivant de l’application destinataire.

La doctrine de Lu Heng sur la spécification initiale minimale invite à garder un socle commun étroit et à rendre les choix futurs explicites. Sa distinction des couches de réalité empêche le certificat, l’annonce, la structure, le calcul privé et la décision métier de se remplacer mutuellement. La primauté du code en fonctionnement exige enfin une observation du traitement réel, non une promesse déduite d’un OID.

Sources