Utilisation des algorithmes de cryptographie de courbe elliptique (ECC) dans la syntaxe de message cryptographique (CMS)

Statut du présent mémoire

Ce mémoire donne des informations pour la communauté de l'Internet. Il ne spécifie aucune forme de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé

Le présent document décrit comment utiliser les algorithmes à clé publique de cryptographie de courbe elliptique (ECC, Elliptic Curve Cryptography) dans la syntaxe de message cryptographique (CMS, Cryptographic Message Syntax). L'algorithme ECC accepte la création de signatures numériques et l'échange de clés pour chiffrer ou authentifier le contenu. La définition du traitement de l'algorithme se fonde sur la norme ANSI X9.62, développée par le groupe de travail ANSI X9F1, la norme IEEE 1363, et la norme SEC 1.

Le lecteur est invité à porter son attention sur la section Droits de propriété intellectuelle à la fin de ce document.

Table des matières

1   Introduction

1.1   Exigences de terminologie

2   SignedData utilisant ECC  ..

2.1   SignedData utilisant ECDSA

2.1.1   Champs de SignedData

2.1.2   Actions de l'agent qui envoie

2.1.3   Actions de l'agent qui reçoit

3   EnvelopedData en utilisant les algorithmes d'ECC

3.1   EnvelopedData en utilisant ECDH (statique éphémère)

3.1.1   Champs de KeyAgreeRecipientInfo

3.1.2   Actions de l'agent qui envoie

3.1.3   Actions de l'agent qui reçoit

3.2   EnvelopedData en utilisant 1-Pass ECMQV

3.2.1   Champs de KeyAgreeRecipientInfo

3.2.2   Actions de l'agent qui envoie

3.2.3   Actions de l'agent qui reçoit

4   AuthenticatedData en utilisant ECC

4.1   AuthenticatedData en utilisant ECMQV à une passe

4.1.1   Champs de KeyAgreeRecipientInfo

4.1.2   Actions de l'agent qui envoie

4.1.3   Actions de l'agent qui reçoit

5   Algorithmes et courbes élliptiques recommandées

6   Certificats qui utilsent ECC

7   Attribut SMIMECapabilities et ECC

8   Syntaxe ASN.1

8.1   Identifiants d'algorithme

8.2   Autre syntaxe

9   Résumé

Références

Déclaration de droits de propriété intellectuelle  .

Déclaration complète de droits de reproduction

1   Introduction

La syntaxe de message cryptographique (CMS, Cryptographic Message Syntax) est indépendante de l'algorithme cryptographique. La présente spécification définit un profil pour l'utilisation des algorithmes à clé publique de cryptographie à courbe elliptique (ECC, Elliptic Curve Cryptography) dans la CMS. Les algorithmes ECC sont incorporés dans les types de contenu de CMS suivants :

-   'SignedData' pour la prise en charge de méthodes de signature numériques fondées sur ECC (ECDSA) du contenu,

-   'EnvelopedData' pour la prise en charge de méthodes d'accord de clé publique fondée sur ECC (ECDH et ECMQV) pour générer des clés de chiffrement de clé par paires pour chiffrer les clés de chiffrement de contenu,

-   'AuthenticatedData' pour la prise en charge de méthodes d'accord de clé publique fondée sur ECC (ECMQV) pour générer des clés de chiffrement de clé par paires pour chiffrer les clés de MAC utilisées pour l'authentification et l'intégrité des contenus,

La certification des clés publiques EC est aussi décrite pour fournir la distribution de clés publiques à l'appui des techniques spécifiées.

1.1   Exigences de terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans le BCP 14, RFC 2119 [DOIT].

2   SignedData utilisant ECC

Cette section décrit comment utiliser les algorithmes ECC avec le format CMS SignedData pour signer les données.

2.1   SignedData utilisant ECDSA

Ce paragraphe décrit comment utiliser l'algorithme de signature numérique à courbe elliptique (ECDSA, Elliptic Curve Digital Signature Algorithm) avec SignedData. ECDSA est spécifié dans [X9.62]. La méthode est la courbe elliptique analogique de l'algorithme de signature numérique (DSA, Digital Signature Algorithm) [FIPS 186-2].

Dans une mise en œuvre qui utilise ECDSA avec la CMS SignedData, les techniques et formats suivants DOIVENT être utilisés.

2.1.1   Champs de SignedData

Lorsqu'on utilise ECDSA avec SignedData, les champs de SignerInfo sont comme dans [CMS], mais avec les restrictions suivantes :

digestAlgorithm DOIT contenir l'identifiant d'algorithme sha-1 (voir au paragraphe 8.1) qui identifie l'algorithme de hachage SHA-1.

signatureAlgorithm contient l'identifiant d'algorithme ecdsa-with-SHA1 (voir au paragraphe 8.1) qui identifie l'algorithme de signature ECDSA.

signature DOIT contenir le codage en DER (comme chaîne d'octets) d'une valeur du type ASN.1 ECDSA-Sig-Value (voir le paragraphe 8.2).

Lorsqu'on utilise ECDSA, le champ des certificats SignedData PEUT inclure le ou les certificats pour la ou les clés publiques de courbe elliptique utilisées pour générer les signatures ECDSA dans SignedData. Les certificats d'ECC sont exposés à la Section 6.

2.1.2   Actions de l'agent qui envoie

Lorsqu'on utilise ECDSA avec SignedData, l'agent qui envoie utilise le processus de calcul de résumé de message et le processus de génération de signature pour SignedData qui sont spécifiés dans [CMS]. Pour signer les données, l'agent qui envoie utilise la méthode de signature spécifiée dans [X9.62, paragraphe 5.3] avec les exceptions suivantes :

-   Dans [X9.62, paragraphe 5.3.1], l'entier "e" est plutôt déterminé en convertissant le résumé de message généré conformément à [CMS, paragraphe 5.4] en un entier en utilisant la méthode de conversion de données de [X9.62, paragraphe 4.3.2].

L'agent qui envoie code la signature qui en résulte avec la syntaxe ECDSA-Sig-Value (voir au paragraphe 8.2) et la place dans le champ de signature SignerInfo.

2.1.3   Actions de l'agent qui reçoit

Lorsqu'on utilise ECDSA avec SignedData, l'agent qui reçoit utilise le processus de calcul de résumé de message et le processus de vérification de signature pour SignedData qui sont spécifiés dans [CMS]. Pour vérifier SignedData, l'agent qui reçoit utilise la méthode de vérification de signature spécifiée dans [X9.62, paragraphe 5.4] avec les exceptions suivantes :

-   Dans [X9.62, paragraphe 5.4.1] l'entier "e" est plutôt déterminé en convertissant le résumé de message généré conformément à [CMS, paragraphe 5.4] en un entier en utilisant la méthode de conversion de données de [X9.62, paragraphe 4.3.2].

Afin de vérifier la signature, l'agent qui reçoit restitue les entiers r et s à partir du champ de signature SignerInfo du message reçu.

3   EnvelopedData en utilisant les algorithmes d'ECC

Cette section décrit comment utiliser les algorithmes d'ECC avec le format EnvelopedData de CMS.

3.1   EnvelopedData en utilisant ECDH (statique éphémère)

Ce paragraphe décrit comment utiliser l'algorithme d'accord de clé Diffie-Hellman à courbe elliptique (ECDH, Elliptic Curve Diffie-Hellman) statique éphémère avec EnvelopedData. L'ECDH statique éphémère est spécifié dans [SEC1] et [IEEE1363]. L'ECDH statique éphémère est la courbe elliptique analogue de l'algorithme d'accord de clé Diffie-Hellman statique éphémère spécifié conjointement dans les documents [CMS, paragraphe 12.3.1.1] et [CMS-DH].

Dans une mise en œuvre qui utilise ECDH avec le EnvelopedData avec accord de clé de CMS, les techniques et formats suivants DOIVENT être utilisés.

3.1.1   Champs de KeyAgreeRecipientInfo

Quand on utilise ECDH statique éphémère avec EnvelopedData, les champs de KeyAgreeRecipientInfo sont comme dans [CMS], mais avec les restrictions suivantes :

originator DOIT être le originatorKey de remplacement. Le champ d'algorithme originatorKey DOIT contenir l'identifiant d'objet id-ecPublicKey (voir au paragraphe 8.1) avec les paramètres NULS. Le champ publicKey de originatorKey DOIT contenir le codage en DER d'une valeur du type ASN.1 ECPoint (voir au paragraphe 8.2), qui représente la clé publique à courbe elliptique éphémère de l'agent qui envoie.

keyEncryptionAlgorithm DOIT contenir l'identifiant d'objet dhSinglePass-stdDH-sha1kdf-scheme (voir au paragraphe 8.1) si une primitive ECDH standard est utilisée, ou l'identifiant d'objet dhSinglePass-cofactorDH-sha1kdf-scheme (voir au paragraphe 8.1) si la primitive ECDH de cofacteur est utilisée. Le champ paramètres contient KeyWrapAlgorithm. Le paramètre KeyWrapAlgorithm est l'identifiant d'algorithme qui indique l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement du contenu (CEK, content-encryption key) avec la clé de chiffrement de clé (KEK, key-encryption key).

3.1.2   Actions de l'agent qui envoie

Lorsqu'il utilise ECDH statique éphémère avec EnvelopedData, l'agent qui envoie obtient d'abord la clé publique à courbe elliptique et les paramètres de domaine du receveur (par exemple d'après le certificat du receveur). L'agent qui envoie détermine ensuite un entier "keydatalen", qui est la taille de la clé symétrique KeyWrapAlgorithm en bits, et aussi une chaîne binaire "SharedInfo", qui est le codage en DER de ECC-CMS-SharedInfo (voir au paragraphe 8.2). L'agent qui envoie effectue alors le développement de clé et l'opération d'accord de clés du schéma Diffie-Hellman à courbe elliptique spécifié dans [SEC1, paragraphe 6.1]. En résultat, l'agent qui envoie obtient :

-   une clé publique éphémère, qui est représentée par une valeur de type ECPoint (voir au paragraphe 8.2), encapsulée dans une chaîne binaire et placée dans le champ d'origine KeyAgreeRecipientInfo,

-   une chaîne binaire "K" de secret partagé, utilisée comme clé de chiffrement de clé par paires pour ce receveur, comme spécifié dans [CMS].

3.1.3   Actions de l'agent qui reçoit

Lorsqu'il utilise l'ECDH éphémère statique avec EnvelopedData, l'agent qui reçoit détermine la chaîne binaire "SharedInfo", qui est le codage en DER de ECC-CMS-SharedInfo (voir au paragraphe 8.2), et l'entier "keydatalen" d'après la taille de clé, en bits, du KeyWrapAlgorithm. L'agent qui reçoit restitue la clé publique à courbe elliptique éphémère d'après la chaîne binaire KeyAgreeRecipientInfo de l'origine, avec une valeur de type ECPoint (voir au paragraphe 8.2) encapsulée comme chaîne binaire. L'agent qui reçoit effectue l'opération d'accord de clés du schéma Diffie-Hellman de courbe elliptique spécifié dans [SEC1, paragraphe 6.1]. En résultat, l'agent qui reçoit obtient une chaîne binaire "K" de secret partagé, qui est utilisée comme clé de chiffrement de clé par paires pour sortir la CEK de son enveloppe.

3.2   EnvelopedData en utilisant 1-Pass ECMQV

Ce paragraphe décrit comment utiliser l'algorithme d'accord de clé MQV (Menezes-Qu-Vanstone) à courbe elliptique à une passe (ECMQV) avec EnvelopedData. ECMQV est spécifié dans [SEC1] et [IEEE1363]. Comme l'algorithme KEA [CMS-KEA], ECMQV à une passe utilise trois paires de clés : une paire de clés éphémères, une paire de clés statiques de l'agent qui envoie, et une paire de clés statiques de l'agent qui reçoit. L'avantage de l'utilisation de ECMQV à une passe est qu'il peut servir à la fois avec EnvelopedData et avec AuthenticatedData.

Dans une mise en œuvre qui utilise ECMQV à une passe avec EnvelopedData avec accord de clés de CMS, les techniques et formats suivants DOIVENT être utilisés.

3.2.1   Champs de KeyAgreeRecipientInfo

Lorsque on utilise ECMQV à une passe avec EnvelopedData, les champs de KeyAgreeRecipientInfo sont :

originator identifie la clé publique à courbe elliptique statique de l'envoyeur. Il DEVRAIT être un de issuerAndSerialNumber ou subjectKeyIdentifier, et pointer sur un des certificats de l'agent qui envoie.

ukm DOIT être présent. Le champ ukm DOIT contenir une chaîne d'octets qui est le codage en DER du type MQVuserKeyingMaterial (voir au paragraphe 8.2). Le champ d'algorithme ephemeralPublicKey de MQVuserKeyingMaterial DOIT contenir l'identifiant d'objet id-ecPublicKey (voir au paragraphe 8.1) avec le champ de paramètres NULL. Le champ publicKey du ephemeralPublicKey de MQVuserKeyingMaterial DOIT contenir le codage en DER du type ASN.1 ECPoint (voir au paragraphe 8.2) représentant la clé publique à courbe elliptique éphémère de l'agent qui envoie. Le champ addedukm de MQVuserKeyingMaterial, s'il est présent, DEVRAIT contenir une chaîne d'octets du matériel de clé d'utilisateur supplémentaire de l'agent qui envoie.

keyEncryptionAlgorithm DOIT être l'identifiant d'algorithme mqvSinglePass-sha1kdf-scheme (voir au paragraphe 8.1), avec le champ de paramètres KeyWrapAlgorithm. KeyWrapAlgorithm indique l'algorithme de chiffrement symétrique utilisé pour chiffrer la CEK avec la KEK générée à l'aide de l'algorithme ECMQV à une passe.

3.2.2   Actions de l'agent qui envoie

Lorsqu'il utilise ECMQV à une passe avec EnvelopedData, l'agent qui envoie obtient d'abord la clé publique à courbe elliptique et les paramètres de domaine du receveur, (par exemple à partir du certificat du receveur) et il vérifie que les paramètres de domaine sont les mêmes. L'agent qui envoie détermine alors un entier "keydatalen", qui est la taille de clé symétrique de KeyWrapAlgorithm en bits, et aussi une chaîne binaire "SharedInfo", qui est le codage en DER de ECC-CMS-SharedInfo (voir au paragraphe 8.2). L'agent qui envoie effectue alors les opérations de développement de clé et d'accord de clés du schéma MQV à courbe elliptique spécifié dans [SEC1, paragraphe 6.2]. Il en résulte que l'agent qui envoie obtient :

-   une clé publique éphémère, qui est représentée par une valeur du type ECPoint (voir au paragraphe 8.2), encapsulée dans une chaîne binaire, placée dans un champ publicKey du ephemeralPublicKey de MQVuserKeyingMaterial (voir au paragraphe 8.2), et

-   une chaîne binaire "K" de secret partagé, qui sert de clé de chiffrement de clés par paires pour ce receveur, comme spécifié dans [CMS].

La clé publique éphémère peut être réutilisée avec une AuthenticatedData pour une efficacité supérieure.

3.2.3   Actions de l'agent qui reçoit

Lorsqu'il utilise ECMQV à une passe avec EnvelopedData, l'agent qui reçoit détermine la chaîne binaire "SharedInfo", qui est le codage en DER de ECC-CMS-SharedInfo (voir au paragraphe 8.2), et l'entier "keydatalen" à partir de la taille de clé, en bits, du paramètre KeyWrapAlgorithm. L'agent qui reçoit restitue alors les clés publiques à courbe elliptique statique et éphémère de l'origine, à partir des champs originator et ukm comme décrit au paragraphe 3.2.1, et de sa clé publique à courbe elliptique statique identifiée dans le champ rid, et il vérifie que les paramètres de domaine sont les mêmes. L'agent qui reçoit effectue alors l'opération d'accord de clés du schéma MQV de courbe elliptique [SEC1, paragraphe 6.2]. Comme résultat, l'agent qui reçoit obtient une chaîne binaire "K" de secret partagé qui est utilisée comme clé de chiffrement de clé par paires pour sortir la CEK de l'enveloppe.

4   AuthenticatedData en utilisant ECC

Cette section décrit comment utiliser les algorithmes d'ECC avec le format CMS AuthenticatedData. AuthenticatedData ne dispose pas de la non répudiation, aussi dans certaines instances il est préférable à SignedData. (Par exemple, l'agent qui envoie pourrait ne pas vouloir que le message soit authentifié lors de la transmission.)

4.1   AuthenticatedData en utilisant ECMQV à une passe

Ce paragraphe décrit comment utiliser l'algorithme d'accord de clé MQV à courbe elliptique à une passe (ECMQV) avec AuthenticatedData. ECMQV est spécifié dans [SEC1]. L'avantage d'utiliser ECMQV à une passe est que cela peut se faire à la fois pour EnvelopedData et pour AuthenticatedData.

4.1.1   Champs de KeyAgreeRecipientInfo

Les champs de AuthenticatedData KeyAgreeRecipientInfo sont utilisés de la même façon que les champs de EnvelopedData KeyAgreeRecipientInfo correspondant du paragraphe 3.2.1 du présent document.

4.1.2   Actions de l'agent qui envoie

L'agent qui envoie utilise les mêmes actions que pour EnvelopedData avec ECMQV à une passe, comme spécifié au paragraphe 3.2.2 du présent document.

La clé publique éphémère peut être réutilisée avec un EnvelopedData pour une meilleure efficacité.

Note : si il y a plusieurs receveurs, une attaque est possible lorsque un des receveurs modifie le contenu sans que les autres receveurs le remarquent [BON]. Un agent qui envoie qui serait concerné par une telle attaque DEVRAIT utiliser un AuthenticatedData distinct pour chaque receveur.

4.1.3   Actions de l'agent qui reçoit

L'agent qui reçoit utilise les mêmes actions que pour EnvelopedData avec ECMQV à une passe, comme spécifié au paragraphe 3.2.2 du présent document.

Note : voir la Note du paragraphe 4.1.2.

5   Algorithmes et courbes elliptiques recommandées

Les mises en œuvre de la présente spécification DOIVENT appliquer SignedData avec ECDSA ou EnvelopedData avec ECDH éphémère statique. Les mises en œuvre de la présente spécification DEVRAIENT appliquer à la fois SignedData avec ECDSA et EnvelopedData avec ECDH éphémère statique. Les mises en œuvre PEUVENT appliquer les autres techniques spécifiées, telles que AuthenticatedData et ECMQV à une passe.

De plus, afin d'encourager l'interopérabilité, les mises en œuvre DEVRAIENT utiliser les paramètres du domaine des courbes elliptiques spécifiés par ANSI [X9.62], NIST [FIPS-186-2] et SECG [SEC2].

6   Certificats qui utilsent ECC

Les certificats X.509 pour l'Internet [PKI] peuvent être utilisés en conjonction avec la présente spécification pour distribuer les clés publiques des agents. L'utilisation des algorithmes et clés ECC au sein de certificats X.509 est spécifiée dans [PKI-ALG].

7   Attribut SMIMECapabilities et ECC

Un agent qui envoie PEUT annoncer aux agents qui reçoivent qu'il prend en charge un ou plusieurs des algorithmes ECC du présent document en utilisant l'attribut SMIMECapabilities signé [MSG, paragraphe 2.5.2].

La valeur de SMIMECapability pour indiquer la prise en charge de l'algorithme de signature ECDSA est la SEQUENCE avec le champ capabilityID contenant l'identifiant d'objet ecdsa-with-SHA1 avec les paramètres NULL. Le codage DER est :

30 0b 06 07 2a 86 48 ce 3d 04 01 05 00

Les identifiants d'objet capabilityID de SMIMECapability pour les algorithmes d'accord de clé pris en charge dans le présent document sont dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass-cofactorDH-sha1kdf-scheme, et mqvSinglePass-sha1kdf-scheme. Pour chacune de ces SEQUENCE de SMIMECapability, le champ parameters est présent et indique l'algorithme key-encryption pris en charge avec l'identifiant d'algorithme KeyWrapAlgorithm. Le codage en DER qui indique cette capacité des trois algorithmes d'accord de clé avec l'enveloppe de clé CMS Triple-DES est :

30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06

0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00

pour l'ECDH éphémère statique,

30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06

0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00

pour l'ECDH éphémère statique avec la méthode du cofacteur, et

30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06

0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00

pour ECMQV.

8   Syntaxe ASN.1

La syntaxe ASN.1 utilisée dans le présent document est rassemblée dans cette section pour faciliter les références.

8.1   Identifiants d'algorithme

Les identifiants d'algorithme utilisés dans le présent document sont tirés de [X9.62], [SEC1] et [SEC2].

L'identifiant d'objet suivant indique l'algorithme de hachage utilisé dans ce document :

sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

L'identifiant d'objet suivant est utilisé dans le présent document pour indiquer une clé publique à courbe elliptique :

id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 }

où

ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 }

Lorsque l'identifiant d'objet id-ecPublicKey est utilisé ici avec un identifiant d'algorithme, les paramètres associés contiennent NULL.

L'identifiant d'objet suivant indique l'algorithme de signature numérique utilisé dans ce document :

ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4) 1 }

Lorsque l'identifiant d'objet ecdsa-with-SHA1 est utilisé au sein d'un identifiant d'algorithme, le champ des paramètres associés contient NULL.

L'identifiant d'objet suivant indique les algorithmes d'accord de clé utilisés dans le présent document :

dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 2}

dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 3}

mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 16}

où

x9-63-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9-63(63) schemes(0) }

Lorsque les identifiants d'objet sont utilisés ici au sein d'un identifiant d'algorithme, le champ des paramètres associés contient l'identifiant d'algorithme CMS KeyWrapAlgorithm.

8.2   Autre syntaxe

La syntaxe supplémentaire suivante est utilisée ici.

Lorsque on utilise ECDSA avec SignedData, les signatures ECDSA sont codées en utilisant le type :

ECDSA-Sig-Value ::= SEQUENCE {

   r INTEGER,

   s INTEGER }

ECDSA-Sig-Value est spécifié dans [X9.62]. Au sein de CMS, ECDSA-Sig-Value est codé en DER et placé au sein d'un champ signature de SignedData.

Lorsque on utilise ECDH et ECMQV avec EnvelopedData et AuthenticatedData, les clés publiques éphémère et statique sont codées en utilisant le type ECPoint.

ECPoint ::= OCTET STRING

Lorsque on utilise ECMQV avec EnvelopedData et AuthenticatedData,la clé publique éphémère et le matériel de clé supplémentaire de l'agent qui en voie sont codées en utilisant le type :

MQVuserKeyingMaterial ::= SEQUENCE {

   ephemeralPublicKey OriginatorPublicKey,

   addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

La syntaxe ECPoint est utilisée pour représenter la clé publique éphémère et la placer dans le champ ephemeralPublicKey. Le matériel supplémentaire de clé d'utilisateur est placé dans le champ addedukm. Puis la valeur MQVuserKeyingMaterial est codée en DER et placée au sein d'un champ ukm de EnvelopedData ou AuthenticatedData.

Lorsque on utilise ECDH ou ECMQV avec EnvelopedData ou AuthenticatedData, les clés de chiffrement de clés sont déduites en utilisant le type :

ECC-CMS-SharedInfo ::= SEQUENCE {

   keyInfo AlgorithmIdentifier,

   entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,

   suppPubInfo [2] EXPLICIT OCTET STRING }

Le champs de ECC-CMS-SharedInfo sont comme suit :

keyInfo contient l'identifiant d'objet de l'algorithme de chiffrement de clé (utilisé pour envelopper la CEK) et les paramètres NULL.

entityUInfo contient facultativement le matériel supplémentaire de clés fourni par l'agent qui envoie. Lorsqu'il est utilisé avec ECDH et CMS, le champ entityUInfo contient la chaîne d'octets ukm. Lorsqu'il est utilisé avec ECMQV et CMS, entityUInfo contient la chaîne d'octets addedukm (codée en MQVuserKeyingMaterial).

suppPubInfo contient la longueur de la KEK générée, en bits, représentée par un nombre de 32 bits, comme dans [CMS-DH]. (Par exemple, pour 3DES ce serait 00 00 00 c0.)

Au sein de CMS, ECC-CMS-SharedInfo est codé en DER et utilisé comme entrée de la fonction de déduction de clé, comme spécifié dans [SEC1, paragraphe 3.6.1]. Noter que ECC-CMS-SharedInfo diffère du OtherInfo spécifié dans [CMS-DH]. Ici, une valeur de compteur n'est pas incluse dans le champ keyInfo parce que la fonction de déduction de clé spécifiée dans [SEC1, paragraphe 3.6.1] assure que des données de clé suffisantes sont fournies.

9   Résumé

Le présent document spécifie comment utiliser les algorithmes ECC avec le CMS S/MIME. L'utilisation de l'algorithme ECC au sein de CMS peut résulter en des exigences de réduction de traitement pour les agents S/MIME, et une bande passante réduite pour les messages CMS.

Références

[X9.62]   ANSI X9.62-1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", American National Standards Institute, 1999.

[BON]   D. Boneh, "The Security of Multicast MAC", Presentation at Selected Areas of Cryptography 2000, Center for Applied Cryptographic Research, University of Waterloo, 2000. Version papier disponible sur http://crypto.stanford.edu/~dabo/papers/mmac.ps

[DOIT]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.

[FIPS-180]   FIPS 180-1, "Secure Hash Standard", National Institute of Standards and Technology, 17 avril 1995.

[FIPS-186-2]   FIPS 186-2, "Digital Signature Standard", National Institute of Standards and Technology, 15 févriery 2000.

[PKI]   R. Housley, W. Polk, W. Ford et D. Solo, "Profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet", RFC 3280, avril 2002.

[CMS]   R. Housley, "Syntaxe de message cryptographique", RFC 2630, juin 1999.

[IEEE1363]   IEEE P1363, "Standard Specifications for Public Key Cryptography", Institute of Electrical and Electronics Engineers, 2000.

[K]   B. Kaliski, "MQV Vulnerabilty", Article sur le bulletin ANSI X9F1 et IEEE P1363, 1998.

[LMQSV]   L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An efficient protocol for authenticated key agreement", Technical report CORR 98-05, University of Waterloo, 1998.

[CMS-KEA]   J. Pawling, "Conventions CMS KEA et SKIPJACK", RFC 2876, juillet 2000.

[MSG]   B. Rmasdell, "Spécification de message S/MIME version 3", RFC 2633, juin 1999.

[CMS-DH]   E. Rescorla, "Méthode d'accord de clé Diffie-Hellman", RFC 2631, juin 1999.

[SEC1]   SECG, "Elliptic Curve Cryptography", Standards for Efficient Cryptography Group, 2000. Disponible sur www.secg.org/collateral/sec1.pdf.

[SEC2]   SECG, "Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography Group, 2000. Disponible sur www.secg.org/collateral/sec2.pdf.

Considérations pour la sécurité

La présente spécification se fonde sur [CMS], [X9.62] et [SEC1] et les considérations appropriées sur la sécurité contenues dans ces documents s'appliquent.

De plus, ceux qui mettent en œuvre AuthenticatedData devraient être conscients des soucis exprimés dans [BON] sur l'utilisation de AuthenticatedData pour envoyer des messages à plus d'un destinataire. Les utilisateurs de MQV devraient aussi être conscients de la vulnérabilité exprimée dans [K].

Lorsque des fonction de hachage sur 256, 384, et 512 bits succèderont à SHA-1 dans des révisions futures de [FIPS], [FIPS-186-2], [X9.62] et [SEC1], elles pourront aussi succéder à SHA-1 dans une révision future du présent document.

Déclaration de droits de propriété intellectuelle

L'IETF a reçu une notification de droits de propriété intellectuelle revendiqués à l'égard de la spécification contenue dans le présent document. Pour plus d'informations, consulter la liste en ligne des revendications de droits (http://www.ietf.org/ipr.html).

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IETF au sujet des droits dans les documents en cours de normalisation et se rapportant aux normes figurent dans le BCP 11.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues du secrétariat de l'IETF.

Remerciement

Les méthodes décrites dans le présent document se fondent sur des travaux du groupe de travail ANSI X9F1. Les auteurs souhaitent étendre leurs remerciements à l'ANSI X9F1 pour son assistance. Les auteurs teinnent aussi à remercier Peter de Rooij pour son assistance patiente. Les commentaires techniques de Francois Rousseau ont été une contribution précieuse.

Adresse des auteurs

Paul Lambert

mél : plambert@sprintmail.com

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.