view Side-By-Side changes
PKIXNetwork Working GroupL. Bassham (NIST) Internet DraftW. Polk Request for Comments: 3279 NIST Obsoletes: 2528 R. Housley(RSA Laboratories) expires April,Category: Standards Track RSA Laboratories L. Bassham NIST April 2002W. Polk (NIST) October, 2001Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate andCRLCertificate Revocation List (CRL) Profile<draft-ietf-pkix-ipki-pkalgs-05.txt>Status of this Memo This documentisspecifies anInternet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents ofInternet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listthis protocol. Distribution ofInternet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html.this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocationlistslist (CRLs). Certificates include the public key of the named subject.Bassham, Housley & Polk [Page 1] INTERNET DRAFT October, 2001Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . .. . . . 62 2 Algorithm Support . . . . . . . . . . . . . . . . . . . .. . . .3 2.1 One-Way Hash Functions . . . . . . . . . . . . . . . .. . . . 43 2.1.1 MD2 One-Way Hash Functions . . . . . . . . . . . . .. . . . 43 2.1.2 MD5 One-Way Hash Functions . . . . . . . . . . . . .. . . .4 2.1.3 SHA-1 One-Way Hash Functions . . . . . . . . . . . .. . . .4 2.2 Signature Algorithms . . . . . . . . . . . . . . . . .. . . . 54 2.2.1 RSA Signature Algorithm . . . . . . . . . . . . . . .. . . .5 2.2.2 DSA Signature Algorithm . . . . . . . . . . . . . . .. . . .6 2.2.3 Elliptic Curve Digital Signature Algorithm . . . . .. . . .7 2.3 Subject Public Key Algorithms . . . . . . . . . . . . .. . . . 87 2.3.1 RSA Keys . . . . . . . . . . . . . . . . . . . . . .. . . .8 2.3.2 DSA Signature Keys . . . . . . . . . . . . . . . . .. . . .9 2.3.3 Diffie-Hellman Key Exchange Keys . . . . . . . . . .. . . .10 Polk, et al. Standards Track [Page 1] RFC 3279 Algorithms and Identifiers April 2002 2.3.4 KEA Public Keys . . . . . . . . . . . . . . . . . . .. . . . 1211 2.3.5 ECDSA and ECDH Public Keys . . . . . . . . . . . . .. . . .13 3 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . .. . . .18 4 References . . . . . . . . . . . . . . . . . . . . . . .. . . . 2324 5 Security Considerations . . . . . . . . . . . . . . . . .. . . .25 6 Intellectual Property Rights . . . . . . . . . . . . . .. . . . 2526 7 Author Addresses . . . . . . . . . . . . . . . . . . . .. . . .26 8 Full Copyright Statement . . . . . . . . . . . . . . . .. . . . 26 Bassham, Housley & Polk [Page 2] INTERNET DRAFT October, 200127 1 Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. This document specifies algorithm identifiers and ASN.1 [X.660] encodingfor- matsformats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). This specification supplements [RFCXXXX],3280], "Internet X.509 Public Key Infrastructure:X.509Certificate andCRL Profile".Certificate Revocation List (CRL) Profile." Implementations of this specificationmustMUST also conform to RFCXXXX.3280. This specification defines the contents of the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and CRLs. This document identifies one-way hash functions for use in thegener- ationgeneration of digital signatures. These algorithms are used inconjunc- tionconjunction with digital signature algorithms. This specification describes the encoding of digital signaturesgen- eratedgenerated with the following cryptographic algorithms: * Rivest-Shamir-Adelman (RSA); * Digital Signature Algorithm (DSA); and * Elliptic Curve Digital Signature Algorithm (ECDSA). This document specifies the contents of the subjectPublicKeyInfo field in Internet X.509 certificates. For each algorithm, theappro- priateappropriate alternatives for the the keyUsage extension are provided. This specification describes encoding formats for public keys used with the following cryptographic algorithms: * Rivest-Shamir-Adelman (RSA); * Digital Signature Algorithm (DSA); *Diffie-Hellman;Diffie-Hellman (DH); * Key Encryption Algorithm (KEA); Polk, et al. Standards Track [Page 2] RFC 3279 Algorithms and Identifiers April 2002 * Elliptic Curve Digital Signature Algorithm (ECDSA); and * Elliptic Curve Diffie-Hellman (ECDH). 2 Algorithm Support This section describes cryptographic algorithms which may be used with the Internet X.509 certificate and CRL profile [RFCXXXX]. The3280]. This section describes one-way hash functions and digital signaturealgo- rithmsalgorithms which may be used to sign certificates and CRLs, andidenti- fies OIDsidentifies object identifiers (OIDs) for public keys contained in a certificate. Conforming CAs and applications MUST, at a minimum, support digitalBassham, Housley & Polk [Page 3] INTERNET DRAFT October, 2001signatures and public keys for one of the specified algorithms. When using any of the algorithms identified in this specification,con- formingconforming CAs and applications MUST support them as described. 2.1 One-way Hash Functions This section identifies one-way hash functions for use in theInter- netInternet X.509 PKI. One-way hash functions are also called message digest algorithms. SHA-1 is the preferred one-way hash function for the Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] and MD5 is used in other legacy applications. Forthis reason,these reasons, MD2 and MD5 are included inthis profile.this profile. The data that is hashed for certificate and CRL signing is fully described in [RFC 3280]. 2.1.1 MD2 One-way Hash Function MD2 was developed by Ron Rivest for RSA Security. RSA Security has recently placed the MD2 algorithm in the public domain. Previously, RSA Data Security had granted license for use of MD2 fornon-commer- cialnon- commercial Internet Privacy-Enhanced Mail (PEM). MD2 may continue to be used with PEM certificates, but SHA-1 is preferred. MD2 produces a 128-bit "hash" of the input. MD2 is fully described in [RFC 1319]. At the Selected Areas in Cryptography '95 conference in May 1995, Rogier and Chauvaud presented an attack on MD2 that can nearly find collisions [RC95]. Collisions occur when one can find two different messages that generate the same message digest. A checksum operation in MD2 is the only remaining obstacle to the success of the attack. For this reason, the use of MD2 for new applications is discouraged. It is still reasonable to use MD2 to verify existing signatures, as the ability to find collisions in MD2 does not enable an attacker to find new messages having a previously computed hash value. Polk, et al. Standards Track [Page 3] RFC 3279 Algorithms and Identifiers April 2002 2.1.2 MD5 One-way Hash Function MD5 was developed by Ron Rivest for RSA Security. RSA Security has placed the MD5 algorithm in the public domain. MD5 produces a128-bit128- bit "hash" of the input. MD5 is fully described in [RFC 1321]. Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, but there are no other known cryptanalytic results. The use of MD5 for new applications is discouraged. It is still reasonable to use MD5 to verify existing signatures. 2.1.3 SHA-1 One-way Hash Function SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit "hash" of the input. SHA-1 is fully described in [FIPS 180-1].Bassham, Housley & Polk [Page 4] INTERNET DRAFT October, 2001 SHA-1 is the one-way hash functionRFC 3174 [RFC 3174] also describes SHA-1, and it provides an implementation ofchoice for use withtheRSA, DSA, and ECDSA signature algorithms.algorithm. 2.2 Signature Algorithms Certificates and CRLs conforming to [RFCXXXX]3280] may be signed with any public key signature algorithm. The certificate or CRL indicates the algorithm through an algorithm identifier which appears in thesigna- tureAlgorithmsignatureAlgorithm field within the Certificate or CertificateList. This algorithm identifier is an OID and has optionally associatedparame- ters.parameters. This section identifies algorithm identifiers and parameters that MUST be used in the signatureAlgorithm field in a Certificate or CertificateList. Signature algorithms are always used in conjunction with a one-way hash function. This section identifies OIDS for RSA, DSA, and ECDSA. The contents of the parameters component for each algorithm vary; details arepro- videdprovided for each algorithm. The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA encryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in thesig- naturesignature field. Polk, et al. Standards Track [Page 4] RFC 3279 Algorithms and Identifiers April 2002 2.2.1 RSA Signature Algorithm The RSA algorithm is named for its inventors: Rivest, Shamir, and Adleman. This profile includes three signature algorithms based on the RSA asymmetric encryption algorithm. The signature algorithms combine RSA with either the MD2, MD5, or the SHA-1 one-way hashfunc- tions.functions. The signature algorithm with SHA-1 and the RSA encryption algorithm is implemented using the padding and encoding conventions described in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 hash algorithm. The RSA signature algorithm, as specified in PKCS #1 [RFC 2313] includes a data encoding step. In this step, the message digest and the OID for the one-way hash function used to compute the digest are combined. When performing the data encoding step, the md2, md5, and id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way hashfunctions respectively : Bassham, Housley & Polk [Page 5] INTERNET DRAFT October, 2001functions, respectively: md2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 2 } md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 } id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } The signature algorithm with MD2 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the ASN.1 OID used to identify this signature algorithm is: md2WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 } The signature algorithm with MD5 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the ASN.1 OID used to identify this signature algorithm is: md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } Polk, et al. Standards Track [Page 5] RFC 3279 Algorithms and Identifiers April 2002 The ASN.1 object identifier used to identify this signature algorithm is: sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } When any of these three OIDs appears within the ASN.1 typeAlgorith- mIdentifier,AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1 type NULL. The RSA signature generation process and the encoding of the result is described in detail in PKCS #1 [RFC 2313]. 2.2.2 DSA Signature Algorithm The Digital Signature Algorithm (DSA) is defined in the DigitalSig- natureSignature Standard (DSS). DSA was developed by the U.S. Government, and DSA is used in conjunction with the SHA-1 one-way hash function. DSABassham, Housley & Polk [Page 6] INTERNET DRAFT October, 2001is fully described in [FIPS 186]. The ASN.1 OID used to identify this signature algorithm is: id-dsa-with-sha1IDOBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } When the id-dsa-with-sha1 algorithm identifier appears as thealgo- rithmalgorithm field in an AlgorithmIdentifier, the encoding SHALL omit the parameters field. That is, the AlgorithmIdentifiershallSHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1. The DSA parameters in the subjectPublicKeyInfo field of thecertifi- catecertificate of the issuershallSHALL apply to the verification of the signature. When signing, the DSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they SHALL be ASN.1 encoded using thefol- lowingfollowing ASN.1 structure: Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } Polk, et al. Standards Track [Page 6] RFC 3279 Algorithms and Identifiers April 2002 2.2.3 ECDSA Signature Algorithm The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. The ASN.1 object identifiers used to identify ECDSA are defined in the following arc: ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 } id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } ECDSA is used in conjunction with the SHA-1 one-way hash function. The ASN.1 object identifier used to identify ECDSA with SHA-1 is:id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } When the ecdsa-with-SHA1 algorithm identifier appears as thealgo- rithmalgorithm field in an AlgorithmIdentifier, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifiershallSHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1. The elliptic curve parameters in the subjectPublicKeyInfo field of the certificate of the issuershallSHALL apply to the verification of the signature.Bassham, Housley & Polk [Page 7] INTERNET DRAFT October, 2001When signing, the ECDSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they MUST be ASN.1 encoded using thefollow- ingfollowing ASN.1 structure: Ecdsa-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } 2.3 Subject Public Key Algorithms Certificates conforming to [RFCXXXX]3280] may convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. This algorithm identifier is an OID and optionally associated parameters. This section identifies preferred OIDs and parameters for the RSA, DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms. Conforming CAs MUST use the identified OIDs when issuing certificates containing Polk, et al. Standards Track [Page 7] RFC 3279 Algorithms and Identifiers April 2002 public keys for these algorithms. Conforming applications supporting any of these algorithms MUST, at a minimum, recognize the OIDidenti- fiedidentified in this section. 2.3.1 RSA Keys The OID rsaEncryption identifies RSA public keys. pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} The rsaEncryption OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field MUST have ASN.1 type NULL for this algorithm identifier. The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey: RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e where modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is the value of the BIT STRING subjectPublicKey. This OID is used in public key certificates for both RSA signature keys and RSA encryption keys. The intended application for the keyBassham, Housley & Polk [Page 8] INTERNET DRAFT October, 2001MAY be indicated in the key usage field (see [RFCXXXX]).3280]). The use of a single key for both signature and encryption purposes is notrecom- mended,recommended, but is not forbidden. If the keyUsage extension is present in an end entity certificate which conveys an RSA public key, any combination of the following values MAY be present: digitalSignature; nonRepudiation; keyEncipherment; and dataEncipherment. If the keyUsage extension is present in a CA or CRL issuer certificate whichcon- veysconveys an RSA public key, any combination of the following values MAY be present: digitalSignature; nonRepudiation; Polk, et al. Standards Track [Page 8] RFC 3279 Algorithms and Identifiers April 2002 keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, both keyEncipherment and dataEncipherment SHOULD NOT be present. 2.3.2 DSA Signature Keys The Digital Signature Algorithm (DSA) is defined in the DigitalSig- natureSignature Standard (DSS) [FIPS 186]. The DSA OID supported by thispro- file isprofile is: id-dsaIDOBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } The id-dsa algorithm syntax includes optional domain parameters. These parameters are commonly referred to as p, q, and g. Whenomit- ted,omitted, the parameters component MUST be omitted entirely. That is, the AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa. If the DSA domain parameters are present in the subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included using the following ASN.1 structure: Dss-Parms ::= SEQUENCE { p INTEGER, q INTEGER,Bassham, Housley & Polk [Page 9] INTERNET DRAFT October, 2001g INTEGER } The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the DSA algorithm parameters are omitted from the subjectPublicKeyInfoAlgo- rithmIdentifierAlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA parameters apply to the subject's DSA key. If the DSA domain parameters are omitted from thesubject- PublicKeyInfoSubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subjectcer- tificatecertificate using a signature algorithm other than DSA, then thesub- ject'ssubject's DSA domain parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the subject's DSA parameters are not available through other means, then clients MUST reject the certificate. Polk, et al. Standards Track [Page 9] RFC 3279 Algorithms and Identifiers April 2002 The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of thesub- jectPublicKeysubjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element. DSAPublicKey ::= INTEGER -- public key, Y If the keyUsage extension is present in an end entity certificate which conveys a DSA public key, any combination of the followingval- uesvalues MAY be present: digitalSignature; nonRepudiation; If the keyUsage extension is present in a CA or CRL issuer certificate whichcon- veysconveys a DSA public key, any combination of the following values MAY be present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign. 2.3.3 Diffie-Hellman Key Exchange Keys The Diffie-Hellman OID supported by this profile is defined in [X9.42]. dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } The dhpublicnumber OID is intended to be used in the algorithm fieldBassham, Housley & Polk [Page 10] INTERNET DRAFT October, 2001of a value of type AlgorithmIdentifier. The parameters field of that type, which has the algorithm-specific syntax ANY DEFINED BYalgo- rithm,algorithm, have the ASN.1 type DomainParameters for this algorithm. DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } Polk, et al. Standards Track [Page 10] RFC 3279 Algorithms and Identifiers April 2002 The fields of type DomainParameters have the following meanings: p identifies the prime p defining the Galois field; g specifies the generator of the multiplicative subgroup of order g; q specifies the prime factor of p-1; j optionally specifies the value that satisfies the equation p=jq+1 to support the optional verification of group parameters; seed optionally specifies the bit string parameter used as the seed for the domain parameter generation process; and pgenCounter optionally specifies the integer value output as part of the of the domain parameter prime generation process. If either of the domain parameter generation components(pgencounter(pgenCounter or seed) is provided, the other MUST be present as well. The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of thesubjectPublicKeyInfoSubjectPublicKeyInfo data element. DHPublicKey ::= INTEGER -- public key, y = g^x mod p If the keyUsage extension is present in a certificate which conveys a DH public key, the following values may be present: keyAgreement; encipherOnly; and decipherOnly.Bassham, Housley & Polk [Page 11] INTERNET DRAFT October, 2001If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly. 2.3.4 KEA Public Keys This section identifies the preferred OID and parameters for the inclusion of a KEA public key in a certificate. The Key Exchange Algorithm (KEA) is a key agreement algorithm. Two parties maygener- ategenerate a "pairwise key" if and only if they share the same KEAparame- ters.parameters. The KEA parameters are not included in a certificate; instead a domain identifier is supplied in the parameters field. Polk, et al. Standards Track [Page 11] RFC 3279 Algorithms and Identifiers April 2002 When thesubjectPublicKeyInfoSubjectPublicKeyInfo field contains a KEA key, the algorithm identifier and parametersshallSHALL be as defined in [SDN.701r]: id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 2 16 840 1 101 2 1 1 22 } KEA-Parms-Id ::= OCTET STRING CAs MUST populate the parameters field of the AlgorithmIdentifier within thesubjectPublicKeyInfoSubjectPublicKeyInfo field of each certificate containing a KEA public key with an 80-bit parameter identifier (OCTET STRING), also known as the domain identifier. The domain identifier iscom- putedcomputed in three steps:1)(1) the KEA domain parameters (p, q, and g) are DER encoded using the Dss-Parms structure; (2) a 160-bit SHA-1 hash is generated from the parameters; and (3) the 160-bit hash is reduced to 80-bits by performing an "exclusive or" of the 80 high order bits with the 80 low order bits. The resulting value is encoded such that the most significant byte of the 80-bit value is the first octet in the octet string. The Dss- Parms is provided above in Section 2.3.2. A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING such that the most significant bit (MSB) of y becomes the MSB of the BIT STRING value field and the least significant bit (LSB) of y becomes the LSB of the BIT STRING value field. This results in the following encoding:Bassham, Housley & Polk [Page 12] INTERNET DRAFT October, 2001BIT STRING tag; BIT STRING length; 0 (indicating that there are zero unused bits in the final octet of y); and BIT STRING value field including y. The key usage extension may optionally appear in a KEA certificate. If a KEA certificate includes the keyUsage extension, only thefol- lowingfollowing values may be asserted: keyAgreement; encipherOnly; and decipherOnly. Polk, et al. Standards Track [Page 12] RFC 3279 Algorithms and Identifiers April 2002 If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly. 2.3.5 ECDSA and ECDH Keys This section identifies the preferred OID and parameter encoding for the inclusion of an ECDSA or ECDH public key in a certificate. The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. ECDSA is the elliptic curve mathematical analog of theDig- italDigital Signature Algorithm [FIPS 186]. The Elliptic Curve DiffieHell- manHellman (ECDH) algorithm is a key agreement algorithm defined in [X9.63]. ECDH is the elliptic curvemathemeticalmathematical analog of the Diffie-Hellman key agreement algorithm as specified in [X9.42].These specifica- tionsThe ECDSA and ECDH specifications use the same OIDs and parameter encodings. The ASN.1 object identifiers used to identify these public keys are defined in the following arc: ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 } When certificates contain an ECDSA or ECDH public key, theid-ecPub- licKeyid-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKeyalgo- rithmalgorithm identifier is defined as follows: id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 } id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } This OID is used in public key certificates for both ECDSA signature keys and ECDH encryption keys. The intended application for the key may be indicated in the key usage field (see [RFCXXXX]).3280]). The use of a single key for both signature and encryption purposesis not Bassham, Housley & Polk [Page 13] INTERNET DRAFT October, 2001is not recommended, but is not forbidden. ECDSA and ECDH require use of certain parameters with the public key. The parameters may be inherited from the issuer, implicitly included through reference to a "named curve," or explicitly included in the certificate. EcpkParameters ::= CHOICE { ecParameters ECParameters, namedCurve OBJECT IDENTIFIER, implicitlyCA NULL } Polk, et al. Standards Track [Page 13] RFC 3279 Algorithms and Identifiers April 2002 When the parameters are inherited, the parameters fieldshallSHALL contain implictlyCA, which is the ASN.1 value NULL. When parameters are specified by reference, the parameters fieldshallSHALL contain thenamed- Curvenamed-Curve choice, which is an object identifier. When the parameters are explicitly included, theyshallSHALL be encoded in the ASN.1 structure ECParameters: ECParameters ::= SEQUENCE { version ECPVer, -- version is always 1 fieldID FieldID, -- identifies the finite field over -- which the curve is defined curve Curve, -- coefficients a and b of the -- elliptic curve base ECPoint, -- specifies the base point P -- on the elliptic curve order INTEGER, -- the order n of the base point cofactor INTEGER OPTIONAL -- The integer h = #E(Fq)/n } ECPVer ::= INTEGER {ecpVer1(1)} Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL } FieldElement ::= OCTET STRING ECPoint ::= OCTET STRING The value of FieldElementshallSHALL be the octet string representation of a field element following the conversion routine in [X9.62], Section 4.3.3. The value of ECPointshallSHALL be the octet string representation of an elliptic curve point following the conversion routine in [X9.62], Section 4.3.6. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form.Bassham, Housley & Polk [Page 14] INTERNET DRAFT October, 2001Implementations that support elliptic curve according to thisspeci- ficationspecification MUST support the uncompressed form and MAY support thecom- pressedcompressed form. The components of type ECParameters have the following meanings: version specifies the version number of the elliptic curveparame- ters.parameters. It MUST have the value 1 (ecpVer1). Polk, et al. Standards Track [Page 14] RFC 3279 Algorithms and Identifiers April 2002 fieldID identifies the finite field over which the elliptic curve is defined. Finite fields are represented by values of theparame- terizedparameterized type FieldID, constrained to the values of the objects defined in the information object set FieldTypes. Additional detail regarding fieldID is provided below. curve specifies the coefficients a and b of the elliptic curve E. Each coefficientshall beis represented as a value of typeFieldEle- ment,FieldElement, an OCTET STRING. seed is an optional parameter used to derive the coefficients of a randomly generated elliptic curve. base specifies the base point P on the elliptic curve. The base pointshall beis represented as a value of type ECPoint, an OCTET STRING. order specifies the order n of the base point. cofactor is the integer h = #E(Fq)/n. This parameter is specified as OPTIONAL. However, the cofactor MUST be included in ECDHpub- licpublic key parameters. The cofactor is not required to support ECDSA, except in parameter validation. The cofactor MAY be included to support parameter validation for ECDSA keys.Parame- terParameter validation is not required by this specification. The AlgorithmIdentifier withinsubjectPublicKeyInfoSubjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If theellip- ticelliptic curve parameters are specified as implicitlyCA in thesubjectPub- licKeyInfoSubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subjectcertifi- catecertificate using ECDSA, then the certificate issuer's ECDSA parameters apply to the subject's ECDSA key. If the elliptic curve parameters are specified as implicitlyCA in thesubjectPublicKeyInfo AlgorithmI- dentifierSubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the certificate using a signaturealgo- rithmalgorithm other than ECDSA, then clients MUST not make use of theellip- ticelliptic curve public key. FieldID ::= SEQUENCE { fieldType OBJECT IDENTIFIER, parameters ANY DEFINED BY fieldType }Bassham, Housley & Polk [Page 15] INTERNET DRAFT October, 2001FieldID is a SEQUENCE of two components, fieldType and parameters. The fieldType contains an object identifier value that uniquelyiden- tifiesidentifies the type contained in the parameters. The object identifier id-fieldType specifies an arc containing the object identifiers of each field type. It has the following value: id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } Polk, et al. Standards Track [Page 15] RFC 3279 Algorithms and Identifiers April 2002 The object identifiers prime-field and characteristic-two-field name the two kinds of fields defined in this Standard. They have thefol- lowingfollowing values: prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } Prime-p ::= INTEGER -- Field size p (p in bits) characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m basis OBJECT IDENTIFIER, parameters ANY DEFINED BY basis } The object identifier id-characteristic-two-basis specifies an arc containing the object identifiers for each type of basis for the characteristic-two finite fields. It has the following value: id-characteristic-two-basis OBJECT IDENTIFIER ::= { characteristic-two-field basisType(1) } The object identifiers gnBasis, tpBasis and ppBasis name the three kinds of basis for characteristic-two finite fields defined by [X9.62]. They have the following values: gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } -- for gnBasis, the value of the parameters field is NULL tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } -- type of parameters field for tpBasis is Trinomial Trinomial ::= INTEGER ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }Bassham, Housley & Polk [Page 16] INTERNET DRAFT October, 2001-- type of parameters field for ppBasis is Pentanomial Pentanomial ::= SEQUENCE { k1 INTEGER, k2 INTEGER, k3 INTEGER } Polk, et al. Standards Track [Page 16] RFC 3279 Algorithms and Identifiers April 2002 The elliptic curve public key (an ECPoint which is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curve according to this specification MUST support the uncompressed form and MAY support the compressed form. If the keyUsage extension is present inan end entitya CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present: digitalSignature; nonRepudiation; and keyAgreement. If the keyAgreement value is present, either of the following values MAY be present: encipherOnly; and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly anddeci- pherOnly.decipherOnly. If the keyUsage extension is present in a CA certificate whichcon- veysconveys an elliptic curve public key, any combination of the following values MAY be present: digitalSignature; nonRepudiation; keyAgreement; keyCertSign; and cRLSign. As above, if the keyUsage extension asserts keyAgreement then it MAYBassham, Housley & Polk [Page 17] INTERNET DRAFT October, 2001assert either encipherOnly and decipherOnly. However, thisspecifi- cationspecification RECOMMENDS that if keyCertSign or cRLSign is present,keyA- greement,keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. Polk, et al. Standards Track [Page 17] RFC 3279 Algorithms and Identifiers April 2002 3 ASN.1 Module PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms(17) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All; -- IMPORTS NONE; -- -- One-way Hash Functions -- md2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 } md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 } id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } -- -- DSA Keys and Signatures -- -- OID for DSA public key id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } -- encoding for DSA public key DSAPublicKey ::= INTEGER -- public key, y Dss-Parms ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER } Polk, et al. Standards Track [Page 18] RFC 3279 Algorithms and Identifiers April 2002 -- OID for DSA signature generated with SHA-1 hash id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } -- encoding for DSA signature generated with SHA-1 hash Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } -- -- RSA Keys and Signatures -- ----arc for RSA public key and RSA signature OIDsBassham, Housley & Polk [Page 18] INTERNET DRAFT October, 2001pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } -- OID for RSA public keys rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } -- OID for RSA signature generated with MD2 hash md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } -- OID for RSA signature generated with MD5 hash md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } -- OID for RSA signature generated with SHA-1 hash sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } -- encoding for RSA public key RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e Polk, et al. Standards Track [Page 19] RFC 3279 Algorithms and Identifiers April 2002 -- -- Diffie-Hellman Keys ----dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } -- encoding for DSA public key DHPublicKey ::= INTEGER -- public key, y = g^x mod p DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } -- -- KEA Keys ----id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 2 16 840 1 101 2 1 1 22 } KEA-Parms-Id ::= OCTET STRINGBassham, Housley & Polk [Page 19] INTERNET DRAFT October, 2001-- -- Elliptic Curve Keys, Signatures, and Curves ----ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 } FieldID ::= SEQUENCE { -- Finite field fieldType OBJECT IDENTIFIER, parameters ANY DEFINED BY fieldType } ---- ECDSA signatures -- -- --Arc for ECDSA signature OIDS id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } Polk, et al. Standards Track [Page 20] RFC 3279 Algorithms and Identifiers April 2002 -- OID for ECDSA signatures with SHA-1 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } -- OID for an elliptic curve signature -- format for the value of an ECDSA signature value ECDSA-Sig-Value ::= SEQUENCE {r INTEGER, s INTEGER } -- -- Elliptic Curve Keys -- --r INTEGER, s INTEGER } -- recognized field type OIDs are defined in the following arc id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } -- where fieldType is prime-field, the parameters are of type Prime-p prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } Prime-p ::= INTEGER -- Finite field F(p), where p is an odd primeBassham, Housley & Polk [Page 20] INTERNET DRAFT October, 2001-- where fieldType is characteristic-two-field, the parameters are -- of type Characteristic-two characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m basis OBJECT IDENTIFIER, parameters ANY DEFINED BY basis } -- recognized basis type OIDs are defined in the following arc id-characteristic-two-basis OBJECT IDENTIFIER ::= { characteristic-two-field basisType(3) } -- gnbasis is identified by OID gnBasis and indicates -- parameters are NULL gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } -- parameters for this basis are NULL -- trinomial basis is identified by OID tpBasis and indicates -- parameters of type Pentanomial tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } Polk, et al. Standards Track [Page 21] RFC 3279 Algorithms and Identifiers April 2002 -- Trinomial basis representation of F2^m -- Integer k for reduction polynomial xm + xk + 1--Trinomial ::= INTEGER -- for pentanomial basis is identified by OID ppBasis and indicates -- parameters of type Pentanomial ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }Pentanomial ::= SEQUENCE { ---- Pentanomial basis representation of F2^m -- reduction polynomial integers k1, k2, k3 -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1--Pentanomial ::= SEQUENCE { k1 INTEGER, k2 INTEGER, k3 INTEGERBassham, Housley & Polk [Page 21] INTERNET DRAFT October, 2001} -- The object identifiers gnBasis, tpBasis and ppBasis name -- three kinds of basis for characteristic-two finite fields FieldElement ::= OCTET STRING -- Finite field element ECPoint ::= OCTET STRING -- Elliptic curve point -- Elliptic Curve parameters may bespecfiedspecified explicitly, -- specified implicitly through a "named curve", or -- inherited from the CA EcpkParameters ::= CHOICE { ecParameters ECParameters, namedCurve OBJECT IDENTIFIER, implicitlyCA NULL } ECParameters ::= SEQUENCE { -- Elliptic curve parameters version ECPVer, fieldID FieldID, curve Curve, base ECPoint, -- Base point G order INTEGER, -- Order n of the base point cofactor INTEGER OPTIONAL } -- The integer h = #E(Fq)/n}ECPVer ::= INTEGER {ecpVer1(1)} Polk, et al. Standards Track [Page 22] RFC 3279 Algorithms and Identifiers April 2002 Curve ::= SEQUENCE { a FieldElement, -- Elliptic curve coefficient a b FieldElement, -- Elliptic curve coefficient b seed BIT STRING OPTIONAL } id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) } id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } -- Named Elliptic Curves-- -- Standards bodies may define OIDs to represent common -- elliptic curve parameters. Users are encouraged -- to consult relevant standards and specifications to -- determine which OIDs (if any) are appropriate for their -- applications. -- The following OIDS are definedin ANSI X9.62.Bassham, Housley & Polk [Page 22] INTERNET DRAFT October, 2001ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) } c-TwoCurve OBJECT IDENTIFIER ::= { ellipticCurve characteristicTwo(0) }primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 } c2pnb163v2 OBJECT IDENTIFIER ::= { c-TwoCurve 2 } c2pnb163v3 OBJECT IDENTIFIER ::= { c-TwoCurve 3 } c2pnb176w1 OBJECT IDENTIFIER ::= { c-TwoCurve 4 } c2tnb191v1 OBJECT IDENTIFIER ::= { c-TwoCurve 5 } c2tnb191v2 OBJECT IDENTIFIER ::= { c-TwoCurve 6 } c2tnb191v3 OBJECT IDENTIFIER ::= { c-TwoCurve 7 } c2onb191v4 OBJECT IDENTIFIER ::= { c-TwoCurve 8 } c2onb191v5 OBJECT IDENTIFIER ::= { c-TwoCurve 9 } c2pnb208w1 OBJECT IDENTIFIER ::= { c-TwoCurve 10 } c2tnb239v1 OBJECT IDENTIFIER ::= { c-TwoCurve 11 } c2tnb239v2 OBJECT IDENTIFIER ::= { c-TwoCurve 12 } c2tnb239v3 OBJECT IDENTIFIER ::= { c-TwoCurve 13 } c2onb239v4 OBJECT IDENTIFIER ::= { c-TwoCurve 14 } c2onb239v5 OBJECT IDENTIFIER ::= { c-TwoCurve 15 } c2pnb272w1 OBJECT IDENTIFIER ::= { c-TwoCurve 16 } c2pnb304w1 OBJECT IDENTIFIER ::= { c-TwoCurve 17 } c2tnb359v1 OBJECT IDENTIFIER ::= { c-TwoCurve 18 } c2pnb368w1 OBJECT IDENTIFIER ::= { c-TwoCurve 19 } c2tnb431r1 OBJECT IDENTIFIER ::= { c-TwoCurve 20 } primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) } prime192v1 OBJECT IDENTIFIER ::= { primeCurve 1 } prime192v2 OBJECT IDENTIFIER ::= { primeCurve 2 } prime192v3 OBJECT IDENTIFIER ::= { primeCurve 3 } prime239v1 OBJECT IDENTIFIER ::= { primeCurve 4 } prime239v2 OBJECT IDENTIFIER ::= { primeCurve 5 } prime239v3 OBJECT IDENTIFIER ::= { primeCurve 6 } prime256v1 OBJECT IDENTIFIER ::= { primeCurve 7 } END Polk, et al. Standards Track [Page 23] RFC 3279 Algorithms and Identifiers April 2002 4 References [FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.] [FIPS 186-2] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 27 January 2000. [Supersedes FIPS PUB 186-1 dated 15 December 1998.]Bassham, Housley & Polk [Page 23] INTERNET DRAFT October, 2001[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," Presented at Selected Areas in Cryptography '95, May 1995. [RFC 1034]P.V.Mockapetris, P., "DomainnamesNames -conceptsConcepts andfacilities",Facilities", STD 13, RFC 1034, November 1987. [RFC 1319] Kaliski, B., "The MD2 Message-DigestAlgorithm,"Algorithm", RFC 1319, April 1992. [RFC 1321] Rivest, R., "The MD5 Message-DigestAlgorithm,"Algorithm", RFC 1321, April 1992. [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based KeyManagement,"Management", RFC 1422, February 1993. [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, andIdentifiers,"Identifiers", RFC 1423, February 1993. [RFC 2119]S.Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2313]B.Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998. [RFC 2459]R.Housley,W.R., Ford, W., Polk, W.Polkand D. Solo "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January, 1999. [RFC 3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. Polk, et al. Standards Track [Page 24] RFC 3279 Algorithms and Identifiers April 2002 [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [SDN.701r] SDN.701, "Message Security Protocol 4.0", Revision A 1997-02-06. [X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988. [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997. [X9.42] ANSI X9.42-2000, "Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", December, 1999. [X9.62] X9.62-1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", January 7, 1999.Bassham, Housley & Polk [Page 24] INTERNET DRAFT October, 2001[X9.63] ANSI X9.63-2001, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic CurveCryptography" (Working Draft), May 8, 2001.Cryptography", Work in Progress. 5 Security Considerations This specification does not constrain the size of public keys or their parameters for use in the Internet PKI. However, the key size selected impacts the strength achieved when implementingcrypto- graphiccryptographic services. Selection of appropriate key sizes is critical to implementing appropriate security. This specification does not identify particular elliptic curves for use in the Internet PKI. However, the particular curve selected impact thethestrength of the digital signatures. Some curves are cryptographically stronger than others! In general, use of "well-known" curves, such as the "named curves" from ANSIX9.62X9.62, is a sound strategy. For additional information, refer to X9.62 Appendix H.1.3, "Key Length Considerations" and Appendix A.1, "Avoiding Cryptographically Weak Keys". Polk, et al. Standards Track [Page 25] RFC 3279 Algorithms and Identifiers April 2002 This specification supplements RFCXXXX.3280. The security considerations section of that document applies to this specification as well. 6 Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in thisdocu- ment.document. For more information consult the online list of claimed rights. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed toper- tainpertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.Bassham, Housley & Polk [Page 25] INTERNET DRAFT October, 20017 Author Addresses:Larry BasshamTim Polk NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USAlbassham@nist.govEMail: tim.polk@nist.gov Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: rhousley@rsasecurity.comTim PolkLarry Bassham NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USAtim.polk@nist.gov 8EMail: lbassham@nist.gov Polk, et al. Standards Track [Page 26] RFC 3279 Algorithms and Identifiers April 2002 8. Full Copyright Statement Copyright (C) The Internet Society(date).(2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.In addition, the ASN.1 modules presented in Appendices A and B may be used in whole or in part without inclusion of the copyright notice.However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose ofdevelop- ingdeveloping Internet standards in which case the procedures for copyrights defined in the Internet Standards processshallmust be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILLBassham, Housley & Polk [Page 26] INTERNET DRAFT October, 2001NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Bassham, Housley & PolkAcknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Polk, et al. Standards Track [Page 27] ----