Résumé

  • La RFC 3058 a attribué des identifiants et des règles de paramètres distincts au chiffrement de contenu IDEA et à l’enveloppement de clé IDEA. La représentation binaire devenait exacte, mais le support restait facultatif et le contexte décidait si les paramètres étaient absents, NULL ou porteurs d’un IV de huit octets.
  • Une capacité S/MIME signée était une déclaration ordonnée du client, non un reçu d’exécution. L’usage réel dépendait encore des deux implémentations, des préférences locales, d’accords privés, de contraintes juridiques, de l’accès aux clés, de l’enveloppement correctement défait et du contenu effectivement traité.

Deux fonctions ne tiennent pas dans un seul nom

Des logiciels cryptographiques ne peuvent pas interopérer sur la simple consigne « utiliser IDEA ». Un message CMS exige un identifiant d’algorithme, ses paramètres et l’emplacement de chaque valeur. Il doit aussi distinguer l’algorithme qui protège le contenu de celui qui protège la clé de chiffrement de ce contenu. Publiée à titre informatif en février 2001, la RFC 3058 a apporté cette précision.

Un OID nommait IDEA en mode CBC pour le contenu. Un second nommait l’enveloppement de clé IDEA. Le premier travaillait sur des blocs de 64 bits avec une clé secrète de 128 bits. Le second prenait une clé de contenu de seize octets, l’associait à une somme de contrôle de huit octets et produisait une valeur enveloppée de 32 octets. Dire qu’un client « prend en charge IDEA » effaçait donc deux fonctions différentes.

Les identifiants se trouvaient sous une branche d’entreprise privée liée à Ascom. Leur rôle était la coordination : des implémentations indépendantes pouvaient émettre le même numéro pour la même fonction. L’enregistrement ne disait pas que tous les clients S/MIME embarquaient le code, que tout utilisateur pouvait l’activer ou qu’un message avait atteint une personne. Il rendait un choix lisible sans le rendre disponible.

Absence, NULL et IV ne sont pas le même vide

Pour le contenu, la structure IDEA-CBCPar pouvait porter un IV d’exactement huit octets. Présent dans les paramètres, cet IV devait être utilisé et ne devait pas être placé au début du texte chiffré. En l’absence du paramètre, les 64 premiers bits du texte chiffré tenaient lieu d’IV, mais la RFC déconseillait cette forme dans CMS ou S/MIME.

L’identifiant d’enveloppement imposait une autre règle : son champ de paramètres devait être NULL. Les deux annonces de capacité S/MIME suivaient une troisième règle : leurs paramètres devaient être absents. Dans une documentation approximative, les trois peuvent être appelés « rien ». En ASN.1, ce sont des octets et des instructions différents.

Voilà le centre discret du document. Un identifiant n’est une instruction complète qu’avec son contexte et sa convention de paramètres. Un parseur qui confond l’absence et NULL peut rejeter une structure valide ou accepter une sémantique jamais convenue. Un tableau de bord qui ne conserve que « IDEA » perd les éléments nécessaires pour reproduire le message.

L’erratum 5913, conservé pour une future mise à jour, le confirme : le symbole ASN.1 IDEA-CBC devrait devenir id-IDEA-CBC afin de commencer conformément par une minuscule. L’OID numérique ne change pas. Le nom destiné au lecteur, l’identifiant du source ASN.1 et le nombre enregistré sont liés, sans être le même objet.

Un hasard intérieur, une constante extérieure

L’enveloppement était défini pas à pas. Une valeur de contrôle de huit octets était ajoutée à la clé de contenu de seize octets. Un IV aléatoire de huit octets servait à chiffrer ces 24 octets avec IDEA-CBC. L’IV aléatoire était ensuite préfixé, les 32 octets inversés, puis l’ensemble chiffré avec l’IV extérieur fixe 4adda22c79e82105. Le déroulement inverse rejetait toute somme de contrôle incorrecte.

Isolé du procédé complet, l’IV extérieur fixe peut tromper : l’IV intérieur frais demeure. Réciproquement, l’aléa et une somme correcte ne prouvent ni l’autorisation du message, ni la volonté du destinataire d’utiliser cet algorithme, ni l’utilité du texte déchiffré. Le contrôle ne répond qu’à une question étroite sur la clé extraite.

CMS séparait les couches parce que leurs tâches différaient. La clé de contenu protégeait le corps ; la clé de chiffrement protégeait cette clé ; le format d’enveloppement la transportait ; l’enveloppe identifiait algorithmes et destinataires. Le succès d’une couche n’acquittait pas les autres.

Une capacité signée, ordonnée et partielle

Un client pouvait publier SMIMECapabilities comme attribut signé. La RFC 3058 fournissait les octets DER exacts pour IDEA-CBC et l’enveloppement, dans deux catégories logiques ; l’ordre exprimait une préférence. Les versions ultérieures de S/MIME ont continué de qualifier cette liste de partielle : le client n’était pas tenu d’énumérer toutes ses capacités.

Une signature validée attribuait donc la déclaration dans le contexte du message signé, sous réserve du certificat et de l’heure de signature. Elle n’interrogeait pas le processus actuel du destinataire. Une mise à niveau, une reconfiguration, un fournisseur cryptographique manquant, une clé inaccessible ou une politique restrictive pouvaient dissocier la déclaration de l’exécution. À l’inverse, une capacité réelle pouvait être omise.

La RFC 3058 laissait elle-même la sélection hors du registre. Elle citait les listes reçues, les accords privés, les préférences utilisateur et les restrictions juridiques. Si l’utilisateur exigeait IDEA, les deux clients devaient le prendre en charge et la préférence devait être réglée. Le registre supprimait l’ambiguïté des octets ; il n’exerçait aucune de ces autorités.

La licence restait à côté du format

La notice de propriété intellectuelle de l’époque indiquait qu’Ascom détenait des brevets, proposait des licences non exclusives à des conditions raisonnables et non discriminatoires, et autorisait gratuitement l’usage non commercial. C’est une preuve historique de la frontière exposée en 2001, non un avis sur le droit actuel. La normalisation technique n’effaçait pas la couche de licence alors déclarée.

Une implémentation pouvait reconnaître l’OID sans contenir l’algorithme. Un développeur pouvait disposer du code tandis qu’une organisation refusait ses conditions. Un destinataire pouvait annoncer la capacité et un expéditeur choisir autre chose. La spécification n’absorbait pas ces décisions dans l’enregistrement.

La RFC 3370 a ensuite séparé les conventions algorithmiques communes du cœur CMS ; la RFC 5652 a défini une version ultérieure de CMS ; la RFC 8551 a donné des niveaux d’exigence à AES et ChaCha20-Poly1305 tout en conservant les capacités et informations hors bande. Cette évolution ne prouve aucun déploiement d’IDEA, et son absence d’une liste moderne obligatoire n’efface pas ses OID.

La leçon durable de la RFC 3058 n’est pas la victoire ou la défaite d’IDEA. La normalisation peut rendre une décision reproductible sans la rendre universelle. Le nombre identifie le choix, les paramètres en donnent la lecture, la capacité signée attribue une déclaration, la politique et le droit conditionnent la sélection. Seul un échange réel montre si les deux extrémités ont accompli le travail.

Sources

Lu Heng n’a ni écrit ni approuvé la RFC 3058. Ses essais servent seulement de grille analytique déclarée pour distinguer l’enregistrement symbolique du comportement exécutable.