Résumé

  • RFC 3657 attribue à Camellia des identifiants CMS distincts pour le chiffrement du contenu et l’encapsulation de clé. En mode CBC, un IV de 16 octets doit être présent ; pour l’identifiant d’encapsulation, les paramètres doivent être absents.
  • L’annonce de capacité S/MIME utilise une troisième forme : un paramètre NULL. L’OID d’encapsulation désigne la taille de la KEK, pas nécessairement celle de la clé de contenu encapsulée.

Le même nom ne désigne pas la même opération

Dans une enveloppe CMS, « Camellia » ne suffit pas à décoder l’opération réalisée par l’expéditeur. Le destinataire doit savoir si l’algorithme chiffre le contenu ou encapsule la clé de chiffrement du contenu (CEK), puis interpréter son identifiant selon ce rôle. Publiée en janvier 2004 comme RFC de la filière Standards Track, la RFC 3657 fixe ces conventions pour Camellia : une famille d’identifiants pour le chiffrement CBC du contenu, une autre pour l’encapsulation de clé. RFC 3657

La différence apparaît dans les paramètres. Pour id-camellia128-cbc, id-camellia192-cbc et id-camellia256-cbc, le champ de paramètres d’AlgorithmIdentifier DOIT être présent et contenir l’IV, une valeur de 16 octets. Cet IV fait partie de la description du chiffrement du contenu ; il ne se déduit pas du nom de l’algorithme. La RFC renvoie aussi aux règles CMS pour le bourrage du texte clair. RFC 3657 RFC 5652

Pour l’encapsulation de clé, l’attente s’inverse. Les trois OID Camellia correspondants portent un arc qui indique une taille de clé, mais les paramètres de leur AlgorithmIdentifier DOIVENT être absents. La construction de wrapping définit elle-même l’emploi de sa valeur initiale interne : aucun IV n’est transmis dans ce champ. La taille de l’OID désigne la clé d’encapsulation (KEK), pas une obligation d’utiliser la même taille pour la CEK encapsulée. Les implémentations DOIVENT prendre en charge des tailles égales ; lorsqu’elles prennent en charge des tailles différentes, la KEK DOIT être au moins aussi longue que la CEK. La RFC décrit donc une frontière d’encodage et de compatibilité, pas une taille unique pour toute l’enveloppe. RFC 3657 RFC 3394

Un troisième encodage pour annoncer une capacité

RFC 3657 précise également comment un client S/MIME annonce son support de Camellia dans SMIMECapabilities. L’OID de capacité est accompagné d’un paramètre NULL. Cela ne contredit pas l’absence de paramètres dans l’identifiant d’encapsulation : il s’agit de structures ASN.1 différentes, avec des fonctions distinctes. NULL n’est pas la même représentation filaire que l’absence de paramètres. La RFC fournit même les encodages DER des trois tailles pour permettre une comparaison précise de la forme annoncée. RFC 3657 RFC 2633

La liste de capacités est signée, ordonnée par préférence et ne constitue qu’une description partielle de ce que l’expéditeur sait faire. Elle alimente une décision ultérieure, avec les accords privés, les préférences de l’utilisateur et les contraintes juridiques. Ce n’est ni une négociation en direct, ni un test de la configuration actuelle du destinataire, ni la preuve qu’un message a utilisé Camellia. Pour connaître l’opération choisie, il faut examiner les algorithmes de contenu et de gestion des clés dans l’enveloppe, pas seulement une annonce antérieure. RFC 3657

La conformité se joue aux frontières

Une revue d’interopérabilité doit comparer séparément ces trois contextes. Pour le contenu CBC, vérifier l’identifiant, la taille de clé attendue et la présence d’un IV de 16 octets. Pour l’encapsulation, vérifier l’absence de paramètres et la relation entre les longueurs réelles de KEK et de CEK selon les capacités déclarées. Pour l’annonce, comparer la valeur DER signée — y compris son NULL — et l’ordre de préférence. Si ces contextes sont confondus, l’encodage ou la négociation peut diverger alors que les systèmes affirment tous prendre en charge le même algorithme.

RFC 3657 dit que l’encapsulation Camellia suit la construction de RFC 3394 en remplaçant AES par Camellia, qui partagent un bloc de 128 bits. La valeur d’intégrité initiale par défaut est la constante A6A6A6A6A6A6A6A6 ; si le désencapsulage ne la retrouve pas, le destinataire renvoie une erreur et ne restitue aucune donnée de clé. La RFC autorise aussi des valeurs initiales différentes pour répondre aux besoins d’intégrité propres à une application. Ce contrôle porte sur les données de clé encapsulées selon cette construction ; il n’authentifie ni l’expéditeur, ni le contenu CMS, ni le droit d’un utilisateur à agir sur le contenu déchiffré. RFC 3657 RFC 3394

Il s’agit d’une reconstruction historique d’un contrat d’encodage, pas d’une recommandation de sécurité ni d’une enquête sur les déploiements. Les registres d’algorithmes CMS et les profils ultérieurs apportent du contexte, mais ne prouvent pas quels produits ont implémenté RFC 3657 ni à quelle fréquence. La leçon est plus étroite : l’identifiant d’algorithme est un champ typé. Il faut lire ensemble son OID, la présence de paramètres et la structure qui l’englobe. RFC 3370 RFC 8419

Sources