Algorithmes et identifiants pour le profil de certificat d'infrastructure
et de liste de révocation de certificat (CRL) de clé publique X.509 pour l'Internet

Statut du présent mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l'Internet. Il appelle à la discussion et à des suggestions pour son amélioration. Prière de se référer à l'édition actuelle des "Normes officielles des protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. 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 spécifie les identifiants d'algorithme et les formats de codage ASN.1 pour les signatures numériques et les clés publiques qui leur sont soumises utilisées dans l'infrastructure de clé publique (PKI) X.509 pour l'Internet. Les signatures numériques sont utilisées pour signer les certificats et la liste de révocation de certificats (CRL). Les certificats incluent la clé publique du sujet désigné.

Table des matières

1   Introduction

2   Prise en charge des algorithmes

2.1   Fonctions de hachage unidirectionnelles

2.1.1   Fonction de hachage MD2 unidirectionnelle

2.1.2   Fonction de hachage MD5 unidirectionnelle

2.1.3   Fonction de hachage SHA-1 unidirectionnelle

2.2   Algorithmes de signature

2.2.1   Algorithme de signature RSA

2.2.2   Algorithme de signature DSA

2.2.3   Algorithme de signature ECDSA

2.3   Algorithmes à clé publique concernés

2.3.1   Clés RSA

2.3.2   Clés de signature DSA

2.3.3   Clés Diffie-Hellman d'échange de clés

2.3.4   Clés publiques KEA

2.3.5   Clés ECDSA et ECDH

3   Module ASN.1

4   Références

5   Considérations pour la sécurité

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

7   Adresse des auteurs

8.   Déclaration complète de droits de reproduction

1   Introduction

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC 2119].

Le présent document spécifie les identifiants d'algorithme et les formats de codage ASN.1 [X.660] pour les signatures numériques et les clés publiques soumises utilisées dans l'infrastructure de clé publique (PKI) X.509 pour l'Internet. La présente spécification complète la [RFC 3280], "Infrastructure de clé publique X.509 pour l'Internet : Profil de certificat et liste de révocation de certificat (CRL)." Les mises en œuvre de la présente spécification DOIVENT aussi se conformer à la RFC 3280.

La présente spécification définit le contenu des champs signatureAlgorithm, signatureValue, signature, et subjectPublicKeyInfo dans les certificats et CRL Internet X.509.

Le présent document identifie des fonctions de hachage unidirectionnel à utiliser dans la génération des signatures numériques. Ces algorithmes sont utilisés en conjonction avec les algorithmes de signature numérique.

La présente spécification décrit le codage des signatures numériques générées avec les algorithmes cryptographiques suivants :

*   Rivest-Shamir-Adelman (RSA);

*   Algorithme de signature numérique (DSA) ; et

*   Algorithme de signature numérique à courbe elliptique (ECDSA).

Le présent document spécifie le contenu du champ subjectPublicKeyInfo dans les certificats Internet X.509. Pour chaque algorithme, les solutions de remplacement appropriées sont fournis pour l'extension keyUsage. Cette spécification décrit les formats de codage pour les clés publiques utilisées avec les algorithmes cryptographiques suivants :

*   Rivest-Shamir-Adelman (RSA) ;

*   Algorithme de signature numérique (DSA, Digital Algorithme de signature) ;

*   Diffie-Hellman (DH) ;

*   Algorithme de chiffrement de clé (KEA, Key Encryption Algorithm) ;

*   Algorithme de signature numérique à courbe elliptique (ECDSA, Elliptic Curve Digital Algorithme de signature) ; et

*   Diffie-Hellman à courbe elliptique (ECDH, Elliptic Curve Diffie-Hellman).

2   Prise en charge des algorithmes

Cette section décrit les algorithmes cryptographiques qui peuvent être utilisés avec le certificat Internet X.509 et le profil CRL [RFC3280]. Elle décrit les fonctions de hachage unidirectionnel et les algorithmes de signature numérique qui peuvent être utilisés pour signer les certificats et les CRL, et identifie les identifiants d'objet (OID) pour les clés publiques contenues dans un certificat.

Les CA et applications conformes DOIVENT, au minimum, accepter les signatures numériques et les clés publiques pour un des algorithmes spécifiés. Lorsqu'ils utilisent un des algorithmes identifiés dans la présente spécification, les CA et applications conformes DOIVENT les accepter comme ils sont décrits.

2.1   Fonctions de hachage unidirectionnelles

Ce paragraphe identifie les fonctions de hachage unidirectionnelles à utiliser dans les PKI Internet X.509. Les fonctions de hachage unidirectionnelles sont aussi appelées algorithmes de résumé de message. SHA-1 est la fonction de hachage unidirectionnelle préférée pour le PKI Internet X.509. Cependant, PEM utilise MD2 pour les certificats des [RFC1422] [RFC1423] et MD5 est utilisé dans d'autres applications traditionnelles. C'est pour cette raison que MD2 et MD5 sont inclus dans ce profil. Les données qui sont hachées pour signer le certificat et la CRL sont complètement décrites dans la [RFC3280].

2.1.1   Fonction de hachage MD2 unidirectionnelle

MD2 a été développé par Ron Rivest pour RSA Security. RSA Security a récemment placé l'algorithme MD2 dans le domaine public. Précédemment, RSA Data Security avait accordé des licences pour l'utilisation de MD2 pour la messagerie à confidentialité améliorée (PEM, Privacy-Enhanced Mail) non commerciale Internet . MD2 peut continuer d'être utilisé avec des certificats PEM, mais SHA-1 est préféré. MD2 produit un "hachage" de 128 bits de l'entrée. MD2 est complètement décrit dans la [RFC1319].

Lors de la conférence "Selected Areas in Cryptography" en mai 1995, Rogier et Chauvaud ont présenté une attaque contre MD2 qui peut presque trouver des collisions [RC95]. Les collisions surviennent lorsqu'on peut trouver deux différents messages qui génèrent le même résumé de message. Une opération de somme de contrôle en MD2 est le seul obstacle restant pour empêcher le succès de l'attaque. Pour cette raison, l'utilisation de MD2 pour de nouvelles applications est déconseillée. Il est encore raisonnable d'utiliser MD2 pour vérifier des signatures existantes, car la capacité de trouver des collisions dans MD2 ne permet pas à un attaquant de trouver de nouveaux messages ayant une valeur de hachage précédemment calculée.

2.1.2   Fonction de hachage MD5 unidirectionnelle

MD5 a été développé par Ron Rivest pour RSA Security. RSA Security a placé l'algorithme MD5 dans le domaine public. MD5 produit un "hachage" de 128 bits d'entrée. MD5 est complètement décrit dans la [RFC1321].

Den Boer et Bosselaers [DB94] ont trouvé des pseudo collisions pour MD5, mais il n'y a pas d'autres résultats cryptanalytiques connus. L'utilisation de MD5 pour de nouvelles applications est déconseillée. Il est toujours raisonnable d'utiliser MD5 pour vérifier les signatures existantes.

2.1.3   Fonction de hachage SHA-1 unidirectionnelle

SHA-1 a été développé par le gouvernement américain. SHA-1 produit un "hachage" de 160 bits de l'entrée. SHA-1 est entièrement décrit dans [FIPS 180-1]. La [RFC3174] décrit aussi SHA-1, et elle donne une mise en œuvre de l'algorithme.

2.2   Algorithmes de signature

Les certificats et CRL conformes à la [RFC3280] peuvent être signés avec tout algorithme de signature à clé publique. Le certificat ou CRL indique l'algorithme au moyen d'un identifiant d'algorithme qui apparaît dans le champ signatureAlgorithm au sein du certificat ou de la liste de certificats. Cet identifiant d'algorithme est un OID et a des paramètres associés facultatifs. Cette section identifie les identifiante d'algorithme et les paramètres qui DOIVENT être utilisés dans le champ signatureAlgorithm dans un certificat ou une liste de certificats.

Les algorithmes de signature sont toujours utilisés en conjonction avec une fonction de hachage unidirectionnelle.

Cette section identifie les OID pour RSA, DSA, et ECDSA. Le contenu des paramètres composants varie pour chaque algorithme ; les détails sont fournis pour chacun d'eux.

Les données à signer (par exemple, la valeur du résultat de la fonction de hachage unidirectionnelle) sont formatées pour l'algorithme de signature à utiliser. Ensuite est effectuée une opération de clé privée (par exemple, un chiffrement RSA) pour générer la valeur de la signature. Cette valeur de signature est ensuite codée en ASN.1 comme une chaîne binaire et incluse dans le certificat ou la liste de certificats dans le champ de signature.

2.2.1   Algorithme de signature RSA

L'algorithme RSA est nommée d'après ses inventeurs : Rivest, Shamir, et Adleman. Ce profil comporte trois algorithmes de signature fondés sur l'algorithme RSA de chiffrement asymétrique. Les algorithmes de signature combinent RSA avec MD2, MD5, ou les fonctions SHA-1 de hachage unidirectionnel.

L'algorithme de signature avec SHA-1 et l'algorithme de chiffrement RSA sont mis en œuvre en utilisant les conventions de bourrage et de codage décrites dans PKCS #1 [RFC2313]. Le résumé de message est calculé en utilisant l'algorithme de hachage SHA-1.

L'algorithme de signature RSA, comme spécifié dans PKCS #1 [RFC2313] comporte une étape de codage des données. Dans cette étape sont combinés le résumé de message et l'OID pour la fonction de hachage unidirectionnelle utilisée pour calculer le résumé. Lorsque on effectue l'étape de codage des données, les OID md2, md5, et id-sha1 DOIVENT être utilisés pour spécifier respectivement les fonctions de hachage unidirectionnelles MD2, MD5, et SHA-1 :

IDENTIFIANT D'OBJET md2 ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 2 }

IDENTIFIANT D'OBJET md5 ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 }

IDENTIFIANT D'OBJET id-sha1 ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 }

L'algorithme de signature avec MD2 et l'algorithme de chiffrement RSA sont définis dans PKCS #1 [RFC2313]. Comme défini dans PKCS #1 [RFC2313], l'OID ASN.1 utilisé pour identifier cet algorithme de signature est :

IDENTIFIANT D'OBJET md2WithRSAEncryption ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }

L'algorithme de signature avec MD5 et l'algorithme de chiffrement RSA sont définis dans PKCS #1 [RFC2313]. Comme défini dans PKCS #1 [RFC2313], l'OID ASN.1 utilisé pour identifier cet algorithme de signature est :

IDENTIFIANT D'OBJET md5WithRSAEncryption ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

L'identifiant d'objet ASN.1 utilisé pour identifier cet algorithme de signature est :

IDENTIFIANT D'OBJET sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

Lorsque un de ces trois OID apparaît dans le type ASN.1 AlgorithmIdentifier, le composant paramètres de ce type DEVRA être le type ASN.1 NULL.

Le processus de génération de signature RSA et le codage du résultat sont décrits en détails dans PKCS #1 [RFC2313].

2.2.2   Algorithme de signature DSA

L'algorithme de signature numérique (DSA) est défini dans la norme de signature numérique (DSS; Digital Signature Standard). DSA a été développé par le gouvernement U.S., et DSA est utilisé en conjonction avec la fonction SHA-1 de hachage unidirectionnel. DSA est complètement décrit dans [FIPS 186]. L'OID ASN.1 utilisé pour identifier cet algorithme de signature est :

IDENTIFIANT D'OBJET id-dsa-with-sha1 ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

Lorsque l'identifiant d'algorithme id-dsa-with-sha1 apparaît comme champ d'algorithme dans un AlgorithmIdentifier, le codage DEVRA omettre le champ Paramètres. C'est-à-dire que AlgorithmIdentifier DEVRA être une SEQUENCE de un composant : l'IDENTIFIANT D'OBJET id-dsa-with-sha1.

Les paramètres DSA dans le champ subjectPublicKeyInfo du certificat du producteur DEVRONT s'appliquer à la vérification de la signature.

Lors de la signature, l'algorithme DSA génère deux valeurs. Ces valeurs sont habituellement appelées r et s. Pour transférer facilement ces deux valeurs comme une signature, elles DEVRONT être codées en ASN.1 en utilisant la structure ASN.1 suivante :

Dss-Sig-Value ::= SEQUENCE { r ENTIER, s ENTIER }

2.2.3   Algorithme de signature ECDSA

L'algorithme de signature numérique à courbe elliptique (ECDSA) est défini dans [X9.62]. Les identifiants d'objet ASN.1 qui sont utilisés pour identifier ECDSA sont définis dans l'arc suivant :

IDENTIFIANT D'OBJET ansi-X9-62 ::= { iso(1) member-body(2) us(840) 10045 }

IDENTIFIANT D'OBJET id-ecSigType ::= { ansi-X9-62 signatures(4) }

ECDSA est utilisé en conjonction avec la fonction de hachage unidirectionnelle SHA-1. L'identifiant d'objet ASN.1 utilisé pour identifier ECDSA avec SHA-1 est :

IDENTIFIANT D'OBJET ecdsa-with-SHA1 ::= { id-ecSigType 1 }

Lorsque l'identifiant d'algorithme ecdsa-with-SHA1 apparaît comme le champ d'algorithme dans un AlgorithmIdentifier, le codage DOIT omettre le champ Paramètres. C'est-à-dire que AlgorithmIdentifier DEVRA être une SEQUENCE de un composant : l'IDENTIFIANT D'OBJET ecdsa-with-SHA1.

Les paramètres de courbe elliptique dans le champ subjectPublicKeyInfo du certificat du producteur DEVRONT s'appliquer à la vérification de la signature.

Lors de la signature, l'algorithme ECDSA génère deux valeurs. Ces valeurs sont habituellement appelées r et s. Pour transférer facilement ces deux valeurs comme une signature, elles DOIVENT être codées en ASN.1 en utilisant la structure ASN.1 suivante :

Ecdsa-Sig-Value ::= SEQUENCE { r ENTIER, s ENTIER }

2.3   Algorithmes à clé publique concernés

Les certificats conformes à la [RFC3280] peuvent porter une clé publique pour tout algorithme à clé publique. Le certificat indique l'algorithme au moyen d'un identifiant d'algorithme. Cet identifiant d'algorithme est un OID et des paramètres associés facultatifs.

Cette section identifie les OID et les paramètres préférés pour les algorithmes RSA, DSA, Diffie-Hellman, KEA, ECDSA, et ECDH. Les CA conformes DOIVENT utiliser les OID identifiés lors de la production de certificats qui contiennent des clés publiques pour ces algorithmes. Les applications conformes qui prennent en charge un de ces algorithmes DOIVENT, au minimum, reconnaître l'OID identifié dans cette section.

2.3.1   Clés RSA

L'OID rsaEncryption identifie les clés publiques RSA.

IDENTIFIANT D'OBJET pkcs-1 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

IDENTIFIANT D'OBJET rsaEncryption ::= { pkcs-1 1}

L'OID rsaEncryption est destiné à être utilisé dans le champ Algorithme d'une valeur de type AlgorithmIdentifier. Le champ Paramètres DOIT avoir le type ASN.1 NULL pour cet identifiant d'algorithme.

La clé publique RSA DOIT être codée en utilisant le type ASN.1 RSAPublicKey :

RSAPublicKey ::= SEQUENCE { modulus ENTIER,    -- n publicExponent ENTIER } -- e

où modulus est le modulo n, et publicExponent est l'exposant public e. La clé RSAPublicKey codée en DER est la valeur de la CHAÎNE BINAIRE subjectPublicKey.

Cet OID est utilisé dans les certificats de clé publique à la fois pour les clés de signature RSA et les clés de chiffrement RSA. L'application prévue pour la clé PEUT être indiquée dans le champ d'utilisation de clé (voir la [RFC3280]). L'usage d'une seule clé pour les deux objets de signature et de chiffrement n'est pas recommandé, mais non interdit.

Si l'extension keyUsage est présente dans un certificat d'entité d'extrémité qui porte une clé publique RSA, toute combinaison des valeurs suivantes PEUT être présente :

digitalSignature,

nonRepudiation,

keyEncipherment,

dataEncipherment.

Si l'extension keyUsage est présente dans un certificat de producteur de CA ou de CRL qui porte une clé publique RSA, toute combinaison des valeurs suivantes PEUT être présente :

digitalSignature,

nonRepudiation,

keyEncipherment,

dataEncipherment,

keyCertSign,

cRLSign.

Cependant, la présente spécification RECOMMANDE que si keyCertSign ou cRLSign est présent, ni keyEncipherment ni dataEncipherment NE DEVRAIT être présents.

2.3.2   Clés de signature DSA

L'algorithme de signature numérique (DSA) est défini dans la norme de signature numérique (DSS) [FIPS 186]. L'OID DSA pris en charge par ce profil est :

IDENTIFIANT D'OBJET id-dsa ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

La syntaxe de l'algorithme id-dsa comporte des paramètres de domaine facultatifs. Ces paramètres sont habituellement appelés p, q, et g. Lorsque il est omis, le composant Paramètres DOIT être omis entièrement. C'est-à-dire que AlgorithmIdentifier DOIT être une SEQUENCE de un composant : l'IDENTIFIANT D'OBJET id-dsa.

Si les paramètres de domaine DSA sont présents dans l'identifiant d'algorithme subjectPublicKeyInfo, les paramètres sont inclus en utilisant la structure ASN.1 suivante :

Dss-Parms ::= SEQUENCE { p ENTIER, q ENTIER, g ENTIER }

L'identifiant d'algorithme au sein de subjectPublicKeyInfo est le seul endroit au sein d'un certificat où les paramètres peuvent être utilisés. Si les paramètres d'algorithme DSA sont omis de l'identifiant d'algorithme subjectPublicKeyInfo et si le CA a signé le certificat concerné en utilisant DSA, les paramètres DSA du producteur du certificat s'appliquent alors à la clé DSA du sujet. Si les paramètres de domaine DSA sont omis de l'identifiant d'algorithme SubjectPublicKeyInfo et si le CA a signé le certificat du sujet en utilisant un algorithme de signature autre que DSA, les paramètres de domaine DSA du sujet sont distribués par d'autres moyens. Si le champ subjectPublicKeyInfo de l'identifiant d'algorithme omet le composant Paramètres, le CA a signé le sujet avec un algorithme de signature autre que DSA, et les paramètres DSA du sujet ne sont pas disponibles par d'autres moyens, les clients DOIVENT alors rejeter le certificat.

La clé publique DSA DOIT être codée en DER ASN.1 comme ENTIER ; ce codage devra être utilisé comme contenu (c'est-à-dire, comme valeur) du composant subjectPublicKey (une CHAÎNE BINAIRE) de l'élément de données SubjectPublicKeyInfo.

DSAPublicKey ::= ENTIER   -- Clé publique, Y

Si l'extension keyUsage est présente dans un certificat d'entité d'extrémité qui porte une clé publique DSA, toute combinaison des valeurs suivantes PEUT être présente :

digitalSignature,

nonRepudiation.

Si l'extension keyUsage est présente dans un certificat de producteur de CA ou CRL qui porte une clé publique DSA, toute combinaison des valeurs suivantes PEUT être présente :

digitalSignature,

nonRepudiation,

keyCertSign,

cRLSign.

2.3.3   Clés Diffie-Hellman d'échange de clés

L'OID Diffie-Hellman pris en charge par ce profil est défini dans [X9.42].

IDENTIFIANT D'OBJET dhpublicnumber ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

L'OID dhpublicnumber est destiné à être utilisé dans le champ Algorithme d'une valeur de type AlgorithmIdentifier. Le champ Paramètres de ce type, qui a la syntaxe spécifique d'algorithme de TOUT CEUX DÉFINIS PAR, a le type ASN.1 DomainParameters pour cet algorithme.

DomainParameters ::= SEQUENCE {

   p ENTIER,    -- premier impair, p=jq +1

   g ENTIER,    -- générateur, g

   q ENTIER,    -- facteur de p-1

   j ENTIER FACULTATIF,    -- facteur de sous-groupe

   validationParms ValidationParms FACULTATIF }

ValidationParms ::= SEQUENCE {

   seed   CHAÎNE BINAIRE,

   pgenCounter   ENTIER }

Les champs de type DomainParameters ont la signification suivante :

p   identifie le nombre premier p qui définit le champ de Galois ;

g   spécifie le générateur du sous-groupe multiplicatif d'ordre g ;

q   spécifie le facteur premier de p-1 ;

j   spécifie facultativement la valeur qui satisfait l'équation p=jq+1 pour prendre en charge la vérification facultative des paramètres de groupe;

seed   spécifie facultativement le paramètre de chaîne binaire utilisé comme germe pour le processus de génération de paramètre de domaine ;

pgenCounter   spécifie facultativement le résultat de valeur entière au titre du processus de génération de nombre premier du paramètre de domaine.

Si un des composants de génération de paramètre de domaine (pgenCounter ou germe) est fourni, l'autre DOIT être présent aussi.

La clé publique Diffie-Hellman DOIT être codée en ASN.1 comme un ENTIER ; ce codage devra être utilisé comme contenu (c'est à dire, comme valeur) du composant subjectPublicKey (une CHAÎNE BINAIRE) de l'élément de données SubjectPublicKeyInfo.

DHPublicKey ::= ENTIER – clé publique, y = g^x mod p

Si l'extension keyUsage est présente dans un certificat qui porte une clé publique DH, les valeurs suivantes peuvent être présentes :

keyAgreement,

encipherOnly,

decipherOnly.

Si elle est présente, l'extension keyUsage DOIT affirmer keyAgreement et PEUT affirmer encipherOnly ou decipherOnly. L'extension keyUsage NE DOIT PAS affirmer à la fois encipherOnly et decipherOnly.

2.3.4   Clés publiques KEA

Ce paragraphe identifie l'OID et les paramètres préférés pour l'inclusion d'une clé publique de KEA dans un certificat. L'algorithme d'échange de clé (KEA, Key Exchange Algorithm) est un algorithme d'échange de clé. Deux parties peuvent générer une "paire de clés couplées" si et seulement si elles partagent les mêmes paramètres de KEA. Les paramètres de KEA ne sont pas inclus dans un certificat, alors qu'un identifiant de domaine est fourni dans le champ Paramètres.

Lorsque le champ SubjectPublicKeyInfo contient une clé de KEA, l'identifiant d'algorithme et les paramètres DEVRONT être comme défini dans [SDN.701r] :

IDENTIFIANT D'OBJET id-keyExchangeAlgorithm ::= { 2 16 840 1 101 2 1 1 22 }

KEA-Parms-Id ::= CHAÎNE D'OCTET

Les CA DOIVENT remplir le champ Paramètres de l'identifiant d'algorithme au sein du champ SubjectPublicKeyInfo de chaque certificat contenant une clé publique de KEA avec un identifiant de paramètre de 80 bits (CHAÎNE D'OCTET) aussi connu sous le nom d'identifiant de domaine. L'identifiant de domaine est calculé en trois étapes :

(1)   les paramètres de domaine de KEA (p, q, et g) sont codés en DER en utilisant la structure Dss-Parms ;

(2)   un hachage SHA-1 de 160 bits est généré à partir des paramètres ;

(3)   le hachage de 160 bits est réduit à 80 bits en effectuant un "ou exclusif" des 80 bits de poids fort avec les 80 bits de moindre poids.

La valeur résultante est codée de telle manière que l'octet de poids fort dans la valeur de 80 bits soit le premier octet dans la chaîne d'octets. Le Dss-Parms est donné ci-dessus au paragraphe 2.3.2.

Une clé publique de KEA , y, est convoyée dans la CHAÎNE BINAIRE subjectPublicKey de telle façon que le bit de poids fort (MSB) de y devienne le MSB du champ de valeur de CHAÎNE BINAIRE et que le bit de moindre poids (LSB) de y devienne le LSB du champ de valeur de CHAÎNE BINAIRE. Il en résulte les codages suivants :

étiquette de CHAÎNE BINAIRE ;

longueur de CHAÎNE BINAIRE ;

0 (indiquant qu'il y a zéro bits non utilisés dans l'octet final de y) ;

champ de valeur de CHAÎNE BINAIRE y compris y.

L'extension d'usage de clé peut facultativement apparaître dans un certificat de KEA. Si un certificat de KEA comporte l'extension keyUsage, seules les valeurs suivantes peuvent être affirmées :

keyAgreement,

encipherOnly,

decipherOnly.

Si elle est présente, l'extension keyUsage DOIT affirmer keyAgreement et PEUT affirmer encipherOnly ou decipherOnly. L'extension keyUsage NE DOIT PAS affirmer à la fois encipherOnly et decipherOnly.

2.3.5   Clés ECDSA et ECDH

Ce paragraphe identifie le codage d'OID et de paramètre préféré pour l'inclusion d'une clé publique ECDSA ou ECDH dans un certificat. L'algorithme de signature numérique à courbe elliptique (ECDSA) est défini dans [X9.62]. ECDSA est l'analogue mathématique à courbe elliptique de l'algorithme de signature numérique [FIPS 186]. L'algorithme Diffie Hellman à courbe elliptique (ECDH, Elliptic Curve Diffie Hellman) est un algorithme d'accord de clé défini dans [X9.63].

ECDH est l'analogue mathématique à courbe elliptique de l'algorithme Diffie-Hellman d'accord de clé spécifié dans [X9.42]. Les spécifications ECDSA et ECDH utilisent les mêmes codages d'OID et de paramètre. Les identifiants d'objet ASN.1 utilisés pour identifier ces clés publiques sont définis dans l'arc suivant :

IDENTIFIANT D'OBJET ansi-X9-62 ::= { iso(1) member-body(2) us(840) 10045 }

Lorsque les certificats contiennent une clé publique ECDSA ou ECDH, l'identifiant d'algorithme id-ecPublicKey DOIT être utilisé. L'identifiant d'algorithme id-ecPublicKey se définit comme suit :

IDENTIFIANT D'OBJET id-public-key-type ::= { ansi-X9.62 2 }

IDENTIFIANT D'OBJET id-ecPublicKey ::= { id-publicKeyType 1 }

Cet OID est utilisé dans les certificats de clés publiques à la fois pour les clés de signature ECDSA et les clés de chiffrement ECDH. L'application prévue pour la clé peut être indiquée dans le champ Utilisation de la clé (voir la [RFC3280]). L'utilisation d'une seule clé à la fois pour la signature et le chiffrement n'est pas recommandée, mais n'est pas interdite.

ECDSA et ECDH exigent l'utilisation de certains paramètres avec la clé publique. Les paramètres peuvent être hérités du producteur, implicitement inclus par référence à une "courbe désignée", ou explicitement inclus dans le certificat.

EcpkParameters ::= CHOICE { ecParameters ECParameters, namedCurve IDENTIFIANT D'OBJET, implicitlyCA NULL }

Lorsque les paramètres sont hérités, le champ Paramètres DEVRA contenir implictlyCA, qui est la valeur ASN.1 NULL. Lorsque les paramètres sont spécifiés par référence, le champ Paramètres DEVRA contenir le choix de la courbe désignée, qui est un identifiant d'objet. Lorsque les paramètres sont explicitement inclus, ils DEVRONT être codés dans la structure ASN.1 ECParameters :

ECParameters ::= SEQUENCE {

   version   ECPVer,   -- la version est toujours 1

   fieldID   FieldID,   -- identifie le champ fini sur lequel est définie la courbe

   curve   Curve,   -- les coefficients a et b de la courbe elliptique spécifient le point P

   base   ECPoint,   -- de base sur la courbe elliptique

   order   ENTIER,   -- l'ordre n du point de base

   cofactor   ENTIER FACULTATIF   -- l'entier h = #E(Fq)/n

}

ECPVer ::= ENTIER {ecpVer1(1)}

Curve ::= SEQUENCE {

   a   FieldElement,

   b   FieldElement,

   seed   CHAÎNE BINAIRE OPTIONAL }

FieldElement ::= CHAÎNE D'OCTET

ECPoint ::= CHAÎNE D'OCTET

La valeur de FieldElement DEVRA être la chaîne d'octets représentant un élément de champ suivant le programme de conversion du paragraphe 4.3.3 de [X9.62]. La valeur de ECPoint DEVRA être la représentation en chaîne d'octets d'un point de courbe elliptique suivant le programme de conversion du paragraphe 4.3.6 de [X9.62]. Noter que cette chaîne d'octets peut représenter un point de courbe elliptique en forme compressée ou non compressée.

Les mises en œuvre qui prennent en charge la courbe elliptique conformément à la présente spécification DOIVENT prendre en charge la forme non compressée et PEUVENT prendre en charge la forme compressée.

Les composants du type ECParameters ont la signification suivante :

version   spécifie le numéro de version des paramètres de courbe elliptique. Ils DOIVENT avoir la valeur 1 (ecpVer1).

fieldID   identifie le champ fini sur lequel est définie la courbe elliptique. Les champs finis sont représentés par des valeurs du type paramétré FieldID, contraints aux valeurs des objets définis dans l'ensemble d'objets d'information FieldTypes. Des précisions supplémentaires concernant fieldID sont fournies ci-dessous.

curve   spécifie les coefficients a et b de la courbe elliptique E. Chaque coefficient est représenté comme une valeur de type FieldElement, qui est une CHAÎNE D'OCTET.

seed   est un paramètre facultatif utilisé pour déduire les coefficients d'une courbe elliptique générée de façon aléatoire.

base   spécifie le point de base P sur la courbe elliptique. Le point de base est représenté comme une valeur de type ECPoint, qui est une CHAÎNE D'OCTET.

order   spécifie l'ordre n du point de base.

cofactor   est l'entier h = #E(Fq)/n. Ce paramètre est spécifié comme FACULTATIF. Cependant, le cofactor DOIT être inclus dans les paramètres de clé publique ECDH. Il n'est pas obligatoire que le cofactor prenne en charge ECDSA, sauf dans la validation de paramètre. Le cofactor PEUT être inclus pour prendre en charge la validation de paramètre pour les clés ECDSA. La validation de paramètres n'est pas rendue obligatoire par la présente spécification.

L'identifiant d'algorithme au sein de SubjectPublicKeyInfo est le seul endroit dans un certificat où les paramètres peuvent être utilisés. Si les paramètres de courbe elliptique sont spécifiés comme implicitlyCA dans l'identifiant d'algorithme SubjectPublicKeyInfo et si le CA a signé le certificat sujet en utilisant ECDSA, les paramètres ECDSA du producteur de certificat s'appliquent à la clé ECDSA du sujet. Si les paramètres de courbe elliptique sont spécifiés comme implicitlyCA dans l'identifiant d'algorithme SubjectPublicKeyInfo et si le CA a signé le certificat en utilisant un algorithme de signature autre que ECDSA, les clients NE DOIVENT pas alors faire usage de la clé publique de courbe elliptique.

FieldID ::= SEQUENCE { fieldType IDENTIFIANT D'OBJET, paramètres TOUS CEUX DÉFINIS PAR fieldType }

FieldID est une SEQUENCE de deux composants, fieldType et paramètres. Le fieldType contient une valeur d'identifiant d'objet qui identifie de façon univoque le type contenu dans paramètres.

L'identifiant d'objet id-fieldType spécifie un arc contenant les identifiants d'objet de chaque type de champ. Il a la valeur suivante :

IDENTIFIANT D'OBJET id-fieldType ::= { ansi-X9-62 fieldType(1) }

Les identifiants d'objet prime-field et characteristic-two-field désignent les deux sortes de champs définis dans la présente norme. Ils ont les valeurs suivantes :

IDENTIFIANT D'OBJET prime-field ::= { id-fieldType 1 }

Prime-p ::= ENTIER   -- Taille de champ p (p en bits)

IDENTIFIANT D'OBJET characteristic-two-field ::= { id-fieldType 2 }

Characteristic-two ::= SEQUENCE {

   m   ENTIER,   -- Taille de champ 2^m

   basis   IDENTIFIANT D'OBJET ,

   paramètres   TOUS CEUX DÉFINIS PAR basis }

L'identifiant d'objet id-characteristic-two-basis spécifie un arc qui contient les identifiants d'objet pour chaque type de basis pour les champs finis characteristic-two. Il a la valeur suivante :

IDENTIFIANT D'OBJET id-characteristic-two-basis ::= { characteristic-two-field basisType(1) }

Les identifiants d'objet gnBasis, tpBasis et ppBasis désignent les trois sortes de basis pour les champs finis characteristic-two définis par [X9.62]. Ils ont les valeurs suivantes :

IDENTIFIANT D'OBJET gnBasis ::= { id-characteristic-two-basis 1 }

-- pour gnBasis, la valeur du champ Paramètres est NULL

IDENTIFIANT D'OBJET tpBasis ::= { id-characteristic-two-basis 2 }

-- le type de champ Paramètres pour tpBasis est Trinomial

Trinomial ::= ENTIER

IDENTIFIANT D'OBJET ppBasis ::= { id-characteristic-two-basis 3 }

-- le type du champ Paramètres pour ppBasis est Pentanomial

Pentanomial ::= SEQUENCE { k1 ENTIER, k2 ENTIER, k3 ENTIER }

La clé publique de courbe elliptique (un ECPoint qui est une CHAÎNE D'OCTET) est transposée en une subjectPublicKey (une CHAÎNE BINAIRE) comme suit : le bit de poids fort de la CHAÎNE D'OCTET devient le bit de poids fort de la CHAÎNE BINAIRE, et le bit de moindre poids de la CHAÎNE D'OCTET devient le bit de moindre poids de la CHAÎNE BINAIRE. Noter que cette chaîne d'octets peut représenter un point de courbe elliptique en forme compressée ou non compressée. Les mises en œuvre qui prennent en charge la courbe elliptique conformément à la présente spécification DOIVENT prendre en charge la forme non compressée et PEUVENT accepter la forme compressée.

Si l'extension keyUsage est présente dans un certificat de producteur de CA ou de CRL qui transporte une clé publique de courbe elliptique, toute combinaison des valeurs suivantes PEUT être présente :

digitalSignature,

nonRepudiation,

keyAgreement.

Si la valueAgreement est présente, une des valeurs suivantes PEUT être présente :

encipherOnly,

decipherOnly.

L'extension keyUsage NE DOIT PAS affirmer à la fois encipherOnly et decipherOnly.

Si l'extension keyUsage est présente dans un certificat de CA qui porte une clé publique de courbe elliptique, toute combinaison des valeurs suivantes PEUT être présente :

digitalSignature,

nonRepudiation,

keyAgreement,

keyCertSign,

cRLSign.

Comme précédemment, si l'extension keyUsage affirme keyAgreement, elle PEUT alors affirmer soit encipherOnly soit decipherOnly. Cependant, cette spécification RECOMMANDE que si keyCertSign ou cRLSign est présent, keyAgreement, encipherOnly, et decipherOnly NE SOIENT PAS présents.

3   Module ASN.1

PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms(17) }

ÉTIQUETTES EXPLICITES DES DÉFINITIONS ::= DÉBUT

-- EXPORTE tout ;

-- IMPORTE NÉANT ;

--

-- Fonctions de hachage unidirectionnelles

--

IDENTIFIANT D'OBJET md2 ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }

IDENTIFIANT D'OBJET md5 ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }

IDENTIFIANT D'OBJET id-sha1 ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 }

--

-- Clés et signatures DSA

--

-- OID pour clés publiques DSA

IDENTIFIANT D'OBJET id-dsa ::= { iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

-- codages pour clés publiques DSA

DSAPublicKey ::= ENTIER   -- clé publique, y

Dss-Parms ::= SEQUENCE {

   p   ENTIER,

   q   ENTIER,

   g   ENTIER }

-- OID pour signature DSA générée avec hachage SHA-1

IDENTIFIANT D'OBJET id-dsa-with-sha1 ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }

-- codage pour signature DSA générée avec hachage SHA-1

Dss-Sig-Value ::= SEQUENCE {

   r   ENTIER,

   s   ENTIER }

--

-- Clés et signatures RSA

--

-- arc pour OID de clé publique RSA et signature RSA

IDENTIFIANT D'OBJET pkcs-1 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

-- OID pour clés publiques RSA

IDENTIFIANT D'OBJET rsaEncryption ::= { pkcs-1 1 }

-- OID pour signature RSA générée avec hachage MD2

IDENTIFIANT D'OBJET md2WithRSAEncryption ::= { pkcs-1 2 }

-- OID pour signature RSA générée avec hachage MD5

IDENTIFIANT D'OBJET md5WithRSAEncryption ::= { pkcs-1 4 }

-- OID pour signature RSA générée avec hachage SHA-1

IDENTIFIANT D'OBJET sha1WithRSAEncryption ::= { pkcs-1 5 }

-- codage pour clé publique RSA

RSAPublicKey ::= SEQUENCE {

   modulus   ENTIER,   -- n

   publicExponent   ENTIER }   -- e

--

-- Clés Diffie-Hellman

--

IDENTIFIANT D'OBJET dhpublicnumber ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

-- codage pour clé publique DSA

DHPublicKey ::= ENTIER   -- clé publique, y = g^x mod p

DomainParameters ::= SEQUENCE {

   p   ENTIER,   -- nombre premier impair, p=jq +1

   g   ENTIER,    -- générateur, g

   q   ENTIER,   -- facteur de p-1

   j   ENTIER FACULTATIF,   -- facteur de sous-groupe, j>= 2

   validationParms   ValidationParms FACULTATIF }

ValidationParms ::= SEQUENCE {

   seed   CHAÎNE BINAIRE,

   pgenCounter   ENTIER }

--

-- Clés de KEA

--

IDENTIFIANT D'OBJET id-keyExchangeAlgorithm ::= { 2 16 840 1 101 2 1 1 22 }

KEA-Parms-Id ::= CHAÎNE D'OCTET

--

-- Clés de courbe elliptique, signatures, et courbes

--

IDENTIFIANT D'OBJET ansi-X9-62 ::= { iso(1) member-body(2) us(840) 10045 }

FieldID ::= SEQUENCE {    -- Champ fini

   fieldType   IDENTIFIANT D'OBJET ,

   paramètres   TOUS CEUX DÉFINIS PAR fieldType }

-- Arc pour OID de signature ECDSA

IDENTIFIANT D'OBJET id-ecSigType ::= { ansi-X9-62 signatures(4) }

-- OID pour signatures ECDSA avec SHA-1

IDENTIFIANT D'OBJET ecdsa-with-SHA1 ::= { id-ecSigType 1 }

-- OID pour un format de signature de courbe elliptique pour la valeur d'une signature ECDSA

ECDSA-Sig-Value ::= SEQUENCE {

   r   ENTIER,

   s   ENTIER }

-- Les OID de type de champ reconnu sont définis dans l'arc suivant

IDENTIFIANT D'OBJET id-fieldType ::= { ansi-X9-62 fieldType(1) }

-- où fieldType est prime-field, les paramètres sont du type Prime-p

IDENTIFIANT D'OBJET prime-field ::= { id-fieldType 1 }

Prime-p ::= ENTIER   -- Champ fini F(p), où p est un nombre premier impair

-- où fieldType est characteristic-two-field, les paramètres sont du type Characteristic-two

IDENTIFIANT D'OBJET characteristic-two-field ::= { id-fieldType 2 }

Characteristic-two ::= SEQUENCE {

   m   ENTIER,   -- Field size 2^m

   basis   IDENTIFIANT D'OBJET ,

   paramètres   TOUS CEUX DÉFINIS PAR basis }

-- Les OID de type basis reconnu sont définis dans l'arc suivant

IDENTIFIANT D'OBJET id-characteristic-two-basis ::= { characteristic-two-field basisType(3) }

-- gnbasis est identifié par l'OID gnBasis et indique que les paramètres sont NULS

IDENTIFIANT D'OBJET gnBasis ::= { id-characteristic-two-basis 1 }

-- les paramètres pour cette base sont NULS

-- la base trinomiale est identifiée par l'OID tpBasis et indique les paramètres de type Pentanomial

IDENTIFIANT D'OBJET tpBasis ::= { id-characteristic-two-basis 2 }

-- La représentation en base trinomiale de F2^m

-- L'entier k pour la réduction polynomiale xm + xk + 1

Trinomial ::= ENTIER

-- pour pentanomial basis est identifié par l'OID ppBasis et indique les paramètres de type Pentanomial

IDENTIFIANT D'OBJET ppBasis ::= { id-characteristic-two-basis 3 }

-- Représentation en base pentanomiale de F2^m

-- entiers k1, k2, k3 de réduction polynomiale

-- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1

Pentanomial ::= SEQUENCE {

   k1   ENTIER,

   k2   ENTIER,

   k3   ENTIER }

-- Les identifiants d'objet gnBasis, tpBasis et ppBasis désignent trois sortes de basis pour les champs finis characteristic-two

FieldElement ::= CHAÎNE D'OCTET   -- Élément de champ fini

ECPoint ::= CHAÎNE D'OCTET   -- Point de courbe elliptique

-- Les paramètres de courbe elliptique peuvent être spécifié de façon explicite, spécifiés de façon implicite à travers une "courbe désignée", ou hérités du CA

EcpkParameters ::= CHOIX {

   ecParameters   ECParameters,

   namedCurve   IDENTIFIANT D'OBJET ,

   implicitlyCA   NULL }

ECParameters ::= SEQUENCE {    -- Version de paramètres de courbe elliptique ECPVer,

   fieldID   FieldID,

   curve   Courbe,

   base   ECPoint,   -- point de base G

   order   ENTIER,    -- Ordre n du point de base

   cofactor   ENTIER FACULTATIF }   -- l'entier h = #E(Fq)/n

ECPVer ::= ENTIER {ecpVer1(1)}

Curve ::= SEQUENCE {

   a   FieldElement,   -- Coefficient a de courbe elliptique

   b   FieldElement,   -- Coefficient b de courbe elliptique

s   seed   CHAÎNE BINAIRE FACULTAIVE }

IDENTIFIANT D'OBJET id-publicKeyType ::= { ansi-X9-62 keyType(2) }

IDENTIFIANT D'OBJET id-ecPublicKey ::= { id-publicKeyType 1 }

-- Courbes elliptiques désignées dans ANSI X9.62.

IDENTIFIANT D'OBJET ellipticCurve ::= { ansi-X9-62 curves(3) }

IDENTIFIANT D'OBJET c-TwoCurve ::= { ellipticCurve characteristicTwo(0) }

IDENTIFIANT D'OBJET c2pnb163v1 ::= { c-TwoCurve 1 }

IDENTIFIANT D'OBJET c2pnb163v2 ::= { c-TwoCurve 2 }

IDENTIFIANT D'OBJET c2pnb163v3 ::= { c-TwoCurve 3 }

IDENTIFIANT D'OBJET c2pnb176w1 ::= { c-TwoCurve 4 }

IDENTIFIANT D'OBJET c2tnb191v1 ::= { c-TwoCurve 5 }

IDENTIFIANT D'OBJET c2tnb191v2 ::= { c-TwoCurve 6 }

IDENTIFIANT D'OBJET c2tnb191v3 ::= { c-TwoCurve 7 }

IDENTIFIANT D'OBJET c2onb191v4 ::= { c-TwoCurve 8 }

IDENTIFIANT D'OBJET c2onb191v5 ::= { c-TwoCurve 9 }

IDENTIFIANT D'OBJET c2pnb208w1 ::= { c-TwoCurve 10 }

IDENTIFIANT D'OBJET c2tnb239v1 ::= { c-TwoCurve 11 }

IDENTIFIANT D'OBJET c2tnb239v2 ::= { c-TwoCurve 12 }

IDENTIFIANT D'OBJET c2tnb239v3 ::= { c-TwoCurve 13 }

IDENTIFIANT D'OBJET c2onb239v4 ::= { c-TwoCurve 14 }

IDENTIFIANT D'OBJET c2onb239v5 ::= { c-TwoCurve 15 }

IDENTIFIANT D'OBJET c2pnb272w1 ::= { c-TwoCurve 16 }

IDENTIFIANT D'OBJET c2pnb304w1 ::= { c-TwoCurve 17 }

IDENTIFIANT D'OBJET c2tnb359v1 ::= { c-TwoCurve 18 }

IDENTIFIANT D'OBJET c2pnb368w1 ::= { c-TwoCurve 19 }

IDENTIFIANT D'OBJET c2tnb431r1 ::= { c-TwoCurve 20 }

IDENTIFIANT D'OBJET primeCurve ::= { ellipticCurve prime(1) }

IDENTIFIANT D'OBJET prime192v1 ::= { primeCurve 1 }

IDENTIFIANT D'OBJET prime192v2 ::= { primeCurve 2 }

IDENTIFIANT D'OBJET prime192v3 ::= { primeCurve 3 }

IDENTIFIANT D'OBJET prime239v1 ::= { primeCurve 4 }

IDENTIFIANT D'OBJET prime239v2 ::= { primeCurve 5 }

IDENTIFIANT D'OBJET prime239v3 ::= { primeCurve 6 }

IDENTIFIANT D'OBJET prime256v1 ::= { primeCurve 7 }

FIN

4   Références

[FIPS 180-1]   Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 avril 1995. [Remplace la FIPS PUB 180 datée du 11 mai 1993.]

[FIPS 186-2]   Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 27 janvier 2000. [Remplace la FIPS PUB 186-1 datée du 15 décembre 1998.]

[P1363]   IEEE P1363, "Standard Specifications for Public-Key Cryptography", 2001.

[RC95]   Rogier, N. and Chauvaud, P., "The compression function of MD2 is not collision free," Présenté à Selected Areas in Cryptography '95, mai 1995.

[RFC1034]   P. Mockapetris, P., "Noms de domaines - Concepts et facilités", STD 13, novembre 1987.

[RFC1319]   B. Kaliski, "Algorithme de résumé de message MD2", avril 1992.

[RFC1422]   S. Kent, "Amélioration de la confidentialité pour la messagerie électronique Internet : Partie II – Gestion de clés fondée sur le certificat", février 1993.

[RFC1423]   D. Balenson, D., "Amélioration de la confidentialité pour la messagerie électronique Internet : Partie III -- Algorithmes, modes et identifiants", février 1993.

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

[RFC2313]   B. Kaliski, "PKCS n° 1 : Chiffrement RSA version 1.5", mars 1998.

[RFC 3174]   D. Eastlake 3 et P. Jones, "Algorithme US de hachage sécurisé n° 1 (SHA1)", septembre 2001.

[RFC3280]   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", avril 2002. (rendue obsolète par la RFC5280)

[SDN.701r]   SDN.701, "Message Security Protocol 4.0", Revision A 1997-02-06.

[X.208]   Recommandation UIT-T X.208 : Spécification de la notation de syntaxe abstraite numéro un (ASN.1), 1988.

[X.660]   Recommandation UIT-T X.660 : Technologies de l'information – Règles de codage ASN.1 : Spécification des règles de codage de base (BER), des règles de codage canonique (CER) et des règles de codage distinctives (DER), 1997.

[X9.42]   ANSI X9.42-2000, "Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", décembre, 1999.

[X9.62]   X9.62-1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", 7 janvier 1999.

[X9.63]   ANSI X9.63-2001, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", Travail en cours.

5   Considérations pour la sécurité

La présente spécification ne met pas de contraintes sur la taille des clés publiques ou celle de leurs paramètres à utiliser dans le PKI Internet. Cependant, la taille choisie pour la clé a un impact sur la force obtenue lors de la mise en œuvre de services de chiffrement. Le choix de tailles de clé appropriées est critique pour la mise en œuvre d'une sécurité appropriée.

La présente spécification n'identifie pas de courbes elliptiques particulières à utiliser dans la PKI Internet. Cependant, la courbe choisie impacte la force des signatures numériques. Certaines courbes sont cryptographiquement plus fortes que d'autres !

En général, l'utilisation de courbes "bien connues", telles que les "courbes nommées" d'après ANSI X9.62, est une bonne stratégie. Pour des informations supplémentaires, se référer à l'Appendice H.1.3, "Key Length Considerations" (considérations sur la longueur des clés) et à l'Appendice A.1, "Avoiding Cryptographically Weak Keys" (éviter les clés cryptographiquement faibles) de X9.62 .

La présente spécification complète la RFC 3280. La section Considérations pour la sécurité de ce document s'applique aussi à la présente spécification.

6   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.

7   Adresse des auteurs

8.   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.