idnits 2.17.1 draft-ietf-pkix-ipki-pkalgs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the ellip-tic curve parameters are specified as implicitlyCA in the subjectPub-licKeyInfo AlgorithmIdentifier and the CA signed the subject certifi-cate 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 the subjectPublicKeyInfo AlgorithmI-dentifier and the CA signed the certificate using a signature algo-rithm other than ECDSA, then clients MUST not make use of the ellip-tic curve public key. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 2119' on line 1093 looks like a reference -- Missing reference section? 'RFC XXXX' on line 587 looks like a reference -- Missing reference section? 'RFC 1423' on line 1089 looks like a reference -- Missing reference section? 'RFC 1319' on line 1079 looks like a reference -- Missing reference section? 'RC95' on line 1072 looks like a reference -- Missing reference section? 'RFC 1321' on line 1082 looks like a reference -- Missing reference section? 'DB94' on line 150 looks like a reference -- Missing reference section? 'FIPS 180-1' on line 1061 looks like a reference -- Missing reference section? 'RFC 2313' on line 1097 looks like a reference -- Missing reference section? 'FIPS 186' on line 566 looks like a reference -- Missing reference section? 'FIPS 186-2' on line 1065 looks like a reference -- Missing reference section? 'P1363' on line 1069 looks like a reference -- Missing reference section? 'RFC 1034' on line 1076 looks like a reference -- Missing reference section? 'RFC 1422' on line 1085 looks like a reference -- Missing reference section? 'RFC 2459' on line 1100 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group L. Bassham (NIST) 3 Internet Draft R. Housley (RSA Laboratories) 4 expires September, 2001 W. Polk (NIST) 5 July, 2001 7 Algorithms and Identifiers for the 8 Internet X.509 Public Key Infrastructure 9 Certificate and CRL Profile 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Drafts Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies algorithm identifiers and ASN.1 encoding 35 formats for digital signatures and subject public keys used in the 36 Internet X.509 Public Key Infrastructure (PKI). Digital signatures 37 are used to sign certificates and certificate revocation lists 38 (CRLs). Certificates include the public key of the named subject. 40 Table of Contents 42 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 43 2 Algorithm Support . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2.1 One-Way Hash Functions . . . . . . . . . . . . . . . . . . . . 4 45 2.1.1 MD2 One-Way Hash Functions . . . . . . . . . . . . . . . . . 4 46 2.1.2 MD5 One-Way Hash Functions . . . . . . . . . . . . . . . . . 4 47 2.1.3 SHA-1 One-Way Hash Functions . . . . . . . . . . . . . . . . 4 48 2.2 Signature Algorithms . . . . . . . . . . . . . . . . . . . . . 5 49 2.2.1 RSA Signature Algorithm . . . . . . . . . . . . . . . . . . . 5 50 2.2.2 DSA Signature Algorithm . . . . . . . . . . . . . . . . . . . 6 51 2.2.3 Elliptic Curve Digital Signature Algorithm . . . . . . . . . 7 52 2.3 Subject Public Key Algorithms . . . . . . . . . . . . . . . . . 8 53 2.3.1 RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 2.3.2 DSA Signature Keys . . . . . . . . . . . . . . . . . . . . . 9 55 2.3.3 Diffie-Hellman Key Exchange Keys . . . . . . . . . . . . . . 10 56 2.3.4 KEA Public Keys . . . . . . . . . . . . . . . . . . . . . . . 12 57 2.3.5 ECDSA and ECDH Public Keys . . . . . . . . . . . . . . . . . 13 58 3 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . 18 59 4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 60 5 Security Considerations . . . . . . . . . . . . . . . . . . . . . 25 61 6 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 25 62 7 Author Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 63 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 26 64 1 Introduction 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC 2119]. 70 This document specifies algorithm identifiers and ASN.1 encoding for- 71 mats for digital signatures and subject public keys used in the 72 Internet X.509 Public Key Infrastructure (PKI). This specification 73 supplements [RFC XXXX], "Internet Public Key Infrastructure: X.509 74 Certificate and CRL Profile". Implementations of this specification 75 must also conform to RFC XXXX. 77 This specification defines the contents of the signatureAlgorithm, 78 signatureValue, signature, and subjectPublicKeyInfo fields within 79 Internet X.509 certificates and CRLs. 81 This document identifies one-way hash functions for use in the gener- 82 ation of digital signatures. These algorithms are used in conjunc- 83 tion with digital signature algorithms. 85 This specification describes the encoding of digital signatures gen- 86 erated with the following cryptographic algorithms: 87 * Rivest-Shamir-Adelman (RSA); 88 * Digital Signature Algorithm (DSA); and 89 * Elliptic Curve Digital Signature Algorithm (ECDSA). 91 This document specifies the contents of the subjectPublicKeyInfo 92 field in Internet X.509 certificates. For each algorithm, the appro- 93 priate alternatives for the the keyUsage extension are provided. 94 This specification describes encoding formats for public keys used 95 with the following cryptographic algorithms: 96 * Rivest-Shamir-Adelman (RSA); 97 * Digital Signature Algorithm (DSA); 98 * Diffie-Hellman; 99 * Key Encryption Algorithm (KEA); 100 * Elliptic Curve Digital Signature Algorithm (ECDSA); and 101 * Elliptic Curve Diffie-Hellman (ECDH). 103 2 Algorithm Support 105 This section describes cryptographic algorithms which may be used 106 with the Internet X.509 certificate and CRL profile [RFC XXXX]. The 107 section describes one-way hash functions and digital signature algo- 108 rithms which may be used to sign certificates and CRLs, and identi- 109 fies OIDs for public keys contained in a certificate. 111 Conforming CAs and applications MUST, at a minimum, support digital 112 signatures and public keys for one of the specified algorithms. When 113 using any of the algorithms identified in this specification, con- 114 forming CAs and applications MUST support them as described. 116 2.1 One-way Hash Functions 118 This section identifies one-way hash functions for use in the Inter- 119 net X.509 PKI. One-way hash functions are also called message digest 120 algorithms. SHA-1 is the preferred one-way hash function for the 121 Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC 122 1422] [RFC 1423] and MD5 is used in other legacy applications. For 123 this reason, MD2 and MD5 are included in this profile. 125 2.1.1 MD2 One-way Hash Function 127 MD2 was developed by Ron Rivest for RSA Security. RSA Security has 128 recently placed the MD2 algorithm in the public domain. Previously, 129 RSA Data Security had granted license for use of MD2 for non-commer- 130 cial Internet Privacy-Enhanced Mail (PEM). MD2 may continue to be 131 used with PEM certificates, but SHA-1 is preferred. MD2 produces a 132 128-bit "hash" of the input. MD2 is fully described in [RFC 1319]. 134 At the Selected Areas in Cryptography '95 conference in May 1995, 135 Rogier and Chauvaud presented an attack on MD2 that can nearly find 136 collisions [RC95]. Collisions occur when one can find two different 137 messages that generate the same message digest. A checksum operation 138 in MD2 is the only remaining obstacle to the success of the attack. 139 For this reason, the use of MD2 for new applications is discouraged. 140 It is still reasonable to use MD2 to verify existing signatures, as 141 the ability to find collisions in MD2 does not enable an attacker to 142 find new messages having a previously computed hash value. 144 2.1.2 MD5 One-way Hash Function 146 MD5 was developed by Ron Rivest for RSA Security. RSA Security has 147 placed the MD5 algorithm in the public domain. MD5 produces a 148 128-bit "hash" of the input. MD5 is fully described in [RFC 1321]. 150 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 151 but there are no other known cryptanalytic results. The use of MD5 152 for new applications is discouraged. It is still reasonable to use 153 MD5 to verify existing signatures. 155 2.1.3 SHA-1 One-way Hash Function 157 SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit 158 "hash" of the input. SHA-1 is fully described in [FIPS 180-1]. 160 SHA-1 is the one-way hash function of choice for use with the RSA, 161 DSA, and ECDSA signature algorithms. 163 2.2 Signature Algorithms 165 Certificates and CRLs conforming to [RFC XXXX] may be signed with any 166 public key signature algorithm. The certificate or CRL indicates the 167 algorithm through an algorithm identifier which appears in the signa- 168 tureAlgorithm field within the Certificate or CertificateList. This 169 algorithm identifier is an OID and has optionally associated parame- 170 ters. This section identifies algorithm identifiers and parameters 171 that MUST be used in the signatureAlgorithm field in a Certificate or 172 CertificateList. 174 Signature algorithms are always used in conjunction with a one-way 175 hash function. 177 This section identifies OIDS for RSA, DSA, and ECDSA. The contents 178 of the parameters component for each algorithm vary; details are pro- 179 vided for each algorithm. 181 The data to be signed (e.g., the one-way hash function output value) 182 is formatted for the signature algorithm to be used. Then, a private 183 key operation (e.g., RSA encryption) is performed to generate the 184 signature value. This signature value is then ASN.1 encoded as a BIT 185 STRING and included in the Certificate or CertificateList in the sig- 186 nature field. 188 2.2.1 RSA Signature Algorithm 190 The RSA algorithm is named for its inventors: Rivest, Shamir, and 191 Adleman. This profile includes three signature algorithms based on 192 the RSA asymmetric encryption algorithm. The signature algorithms 193 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash func- 194 tions. 196 The signature algorithm with SHA-1 and the RSA encryption algorithm 197 is implemented using the padding and encoding conventions described 198 in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 199 hash algorithm. 201 The RSA signature algorithm, as specified in PKCS #1 [RFC 2313] 202 includes a data encoding step. In this step, the message digest and 203 the OID for the one-way hash function used to compute the digest are 204 combined. When performing the data encoding step, the md2, md5, and 205 id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way 206 hash functions respectively : 208 md2 OBJECT IDENTIFIER ::= 209 { iso(1) member-body(2) US(840) rsadsi(113549) 210 digestAlgorithm(2) 2 } 212 md5 OBJECT IDENTIFIER ::= 213 { iso(1) member-body(2) US(840) rsadsi(113549) 214 digestAlgorithm(2) 5 } 216 id-sha1 OBJECT IDENTIFIER ::= { 217 iso(1) identified-organization(3) oiw(14) secsig(3) 218 algorithms(2) 26 } 220 The signature algorithm with MD2 and the RSA encryption algorithm is 221 defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the 222 ASN.1 OID used to identify this signature algorithm is: 224 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 225 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 226 pkcs-1(1) 2 } 228 The signature algorithm with MD5 and the RSA encryption algorithm is 229 defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the 230 ASN.1 OID used to identify this signature algorithm is: 232 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 233 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 234 pkcs-1(1) 4 } 236 The ASN.1 object identifier used to identify this signature algorithm 237 is: 239 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 240 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 241 pkcs-1(1) 5 } 243 When any of these three OIDs appears within the ASN.1 type Algorith- 244 mIdentifier, the parameters component of that type SHALL be the ASN.1 245 type NULL. 247 The RSA signature generation process and the encoding of the result 248 is described in detail in PKCS #1 [RFC 2313]. 250 2.2.2 DSA Signature Algorithm 252 The Digital Signature Algorithm (DSA) is defined in the Digital Sig- 253 nature Standard (DSS). DSA was developed by the U.S. Government, and 254 DSA is used in conjunction with the SHA-1 one-way hash function. DSA 255 is fully described in [FIPS 186]. The ASN.1 OID used to identify 256 this signature algorithm is: 258 id-dsa-with-sha1 ID ::= { 259 iso(1) member-body(2) us(840) x9-57 (10040) 260 x9cm(4) 3 } 262 When the id-dsa-with-sha1 algorithm identifier appears as the algo- 263 rithm field in an AlgorithmIdentifier, the encoding SHALL omit the 264 parameters field. That is, the AlgorithmIdentifier shall be a 265 SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1. 267 The DSA parameters in the subjectPublicKeyInfo field of the certifi- 268 cate of the issuer shall apply to the verification of the signature. 270 When signing, the DSA algorithm generates two values. These values 271 are commonly referred to as r and s. To easily transfer these two 272 values as one signature, they SHALL be ASN.1 encoded using the fol- 273 lowing ASN.1 structure: 275 Dss-Sig-Value ::= SEQUENCE { 276 r INTEGER, 277 s INTEGER } 279 2.2.3 ECDSA Signature Algorithm 281 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 282 [X9.62]. The ASN.1 object identifiers used to identify ECDSA are 283 defined in the following arc: 285 ansi-X9-62 OBJECT IDENTIFIER ::= 286 { iso(1) member-body(2) us(840) 10045 } 288 ECDSA is used in conjunction with the SHA-1 one-way hash function. 289 The ASN.1 object identifier used to identify ECDSA with SHA-1 is: 291 id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } 292 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } 294 When the ecdsa-with-SHA1 algorithm identifier appears as the algo- 295 rithm field in an AlgorithmIdentifier, the encoding MUST omit the 296 parameters field. That is, the AlgorithmIdentifier shall be a 297 SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1. 299 The elliptic curve parameters in the subjectPublicKeyInfo field of 300 the certificate of the issuer shall apply to the verification of the 301 signature. 303 When signing, the ECDSA algorithm generates two values. These values 304 are commonly referred to as r and s. To easily transfer these two 305 values as one signature, they MUST be ASN.1 encoded using the follow- 306 ing ASN.1 structure: 308 Ecdsa-Sig-Value ::= SEQUENCE { 309 r INTEGER, 310 s INTEGER } 312 2.3 Subject Public Key Algorithms 314 Certificates conforming to [RFC XXXX] may convey a public key for any 315 public key algorithm. The certificate indicates the algorithm through 316 an algorithm identifier. This algorithm identifier is an OID and 317 optionally associated parameters. 319 This section identifies preferred OIDs and parameters for the RSA, 320 DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms. Conforming CAs 321 MUST use the identified OIDs when issuing certificates containing 322 public keys for these algorithms. Conforming applications supporting 323 any of these algorithms MUST, at a minimum, recognize the OID identi- 324 fied in this section. 326 2.3.1 RSA Keys 328 The OID rsaEncryption identifies RSA public keys. 330 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 331 rsadsi(113549) pkcs(1) 1 } 333 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 335 The rsaEncryption OID is intended to be used in the algorithm field 336 of a value of type AlgorithmIdentifier. The parameters field MUST 337 have ASN.1 type NULL for this algorithm identifier. 339 The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey: 341 RSAPublicKey ::= SEQUENCE { 342 modulus INTEGER, -- n 343 publicExponent INTEGER } -- e 345 where modulus is the modulus n, and publicExponent is the public 346 exponent e. The DER encoded RSAPublicKey is the value of the BIT 347 STRING subjectPublicKey. 349 This OID is used in public key certificates for both RSA signature 350 keys and RSA encryption keys. The intended application for the key 351 MAY be indicated in the key usage field (see [RFC XXXX]). The use of 352 a single key for both signature and encryption purposes is not recom- 353 mended, but is not forbidden. 355 If the keyUsage extension is present in an end entity certificate 356 which conveys an RSA public key, any combination of the following 357 values MAY be present: 358 digitalSignature; 359 nonRepudiation; 360 keyEncipherment; and 361 dataEncipherment. 363 If the keyUsage extension is present in a CA certificate which con- 364 veys an RSA public key, any combination of the following values MAY 365 be present: 366 digitalSignature; 367 nonRepudiation; 368 keyEncipherment; 369 dataEncipherment; 370 keyCertSign; and 371 cRLSign. 373 However, this specification RECOMMENDS that if keyCertSign or cRLSign 374 is present, both keyEncipherment and dataEncipherment SHOULD NOT be 375 present. 377 2.3.2 DSA Signature Keys 379 The Digital Signature Algorithm (DSA) is defined in the Digital Sig- 380 nature Standard (DSS) [FIPS 186]. The DSA OID supported by this pro- 381 file is 383 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 384 x9cm(4) 1 } 386 The id-dsa algorithm syntax includes optional domain parameters. 387 These parameters are commonly referred to as p, q, and g. When omit- 388 ted, the parameters component MUST be omitted entirely. That is, the 389 AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT 390 IDENTIFIER id-dsa. 392 If the DSA domain parameters are present in the subjectPublicKeyInfo 393 AlgorithmIdentifier, the parameters are included using the following 394 ASN.1 structure: 396 Dss-Parms ::= SEQUENCE { 397 p INTEGER, 398 q INTEGER, 399 g INTEGER } 401 The AlgorithmIdentifier within subjectPublicKeyInfo is the only place 402 within a certificate where the parameters may be used. If the DSA 403 algorithm parameters are omitted from the subjectPublicKeyInfo Algo- 404 rithmIdentifier and the CA signed the subject certificate using DSA, 405 then the certificate issuer's DSA parameters apply to the subject's 406 DSA key. If the DSA domain parameters are omitted from the subject- 407 PublicKeyInfo AlgorithmIdentifier and the CA signed the subject cer- 408 tificate using a signature algorithm other than DSA, then the sub- 409 ject's DSA domain parameters are distributed by other means. If the 410 subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters 411 component, the CA signed the subject with a signature algorithm other 412 than DSA, and the subject's DSA parameters are not available through 413 other means, then clients MUST reject the certificate. 415 The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this 416 encoding shall be used as the contents (i.e., the value) of the sub- 417 jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 418 data element. 420 DSAPublicKey ::= INTEGER -- public key, Y 422 If the keyUsage extension is present in an end entity certificate 423 which conveys a DSA public key, any combination of the following val- 424 ues MAY be present: 426 digitalSignature; 427 nonRepudiation; 429 If the keyUsage extension is present in a CA certificate which con- 430 veys a DSA public key, any combination of the following values MAY be 431 present: 433 digitalSignature; 434 nonRepudiation; 435 keyCertSign; and 436 cRLSign. 438 2.3.3 Diffie-Hellman Key Exchange Keys 440 The Diffie-Hellman OID supported by this profile is 441 defined in [X9.42]. 443 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 444 us(840) ansi-x942(10046) number-type(2) 1 } 446 The dhpublicnumber OID is intended to be used in the algorithm field 447 of a value of type AlgorithmIdentifier. The parameters field of that 448 type, which has the algorithm-specific syntax ANY DEFINED BY algo- 449 rithm, have the ASN.1 type DomainParameters for this algorithm. 451 DomainParameters ::= SEQUENCE { 452 p INTEGER, -- odd prime, p=jq +1 453 g INTEGER, -- generator, g 454 q INTEGER, -- factor of p-1 455 j INTEGER OPTIONAL, -- subgroup factor 456 validationParms ValidationParms OPTIONAL } 458 ValidationParms ::= SEQUENCE { 459 seed BIT STRING, 460 pgenCounter INTEGER } 462 The fields of type DomainParameters have the following meanings: 464 p identifies the prime p defining the Galois field; 466 g specifies the generator of the multiplicative subgroup of order 467 g; 469 q specifies the prime factor of p-1; 471 j optionally specifies the value that satisfies the equation 472 p=jq+1 to support the optional verification of group parameters; 474 seed optionally specifies the bit string parameter used as the 475 seed for the domain parameter generation process; and 477 pgenCounter optionally specifies the integer value output as part 478 of the of the domain parameter prime generation process. 480 If either of the domain parameter generation components (pgencounter 481 or seed) is provided, the other MUST be present as well. 483 The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER; 484 this encoding shall be used as the contents (i.e., the value) of the 485 subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo 486 data element. 488 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 490 If the keyUsage extension is present in a certificate which conveys a 491 DH public key, the following values may be present: 492 keyAgreement; 493 encipherOnly; and 494 decipherOnly. 496 If present, the keyUsage extension MUST assert keyAgreement and MAY 497 assert either encipherOnly and decipherOnly. The keyUsage extension 498 MUST NOT assert both encipherOnly and decipherOnly. 500 2.3.4 KEA Public Keys 502 This section identifies the preferred OID and parameters for the 503 inclusion of a KEA public key in a certificate. The Key Exchange 504 Algorithm (KEA) is a key agreement algorithm. Two parties may gener- 505 ate a "pairwise key" if and only if they share the same KEA parame- 506 ters. The KEA parameters are not included in a certificate; instead 507 a domain identifier is supplied in the parameters field. 509 When the subjectPublicKeyInfo field contains a KEA key, the algorithm 510 identifier and parameters shall be as defined in [SDN.701r]: 512 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= 513 { 2 16 840 1 101 2 1 1 22 } 515 KEA-Parms-Id ::= OCTET STRING 517 CAs MUST populate the parameters field of the AlgorithmIdentifier 518 within the subjectPublicKeyInfo field of each certificate containing 519 a KEA public key with an 80-bit parameter identifier (OCTET STRING), 520 also known as the domain identifier. The domain identifier is com- 521 puted in three steps: 523 1) the KEA domain parameters (p, q, and g) are DER encoded using 524 the Dss-Parms structure; 526 (2) a 160-bit SHA-1 hash is generated from the parameters; and 528 (3) the 160-bit hash is reduced to 80-bits by performing an 529 "exclusive or" of the 80 high order bits with the 80 low order 530 bits. 532 The resulting value is encoded such that the most significant byte of 533 the 80-bit value is the first octet in the octet string. The Dss- 534 Parms is provided above in Section 2.3.2. 536 A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING 537 such that the most significant bit (MSB) of y becomes the MSB of the 538 BIT STRING value field and the least significant bit (LSB) of y 539 becomes the LSB of the BIT STRING value field. This results in the 540 following encoding: 542 BIT STRING tag; 543 BIT STRING length; 544 0 (indicating that there are zero unused bits in the final octet 545 of y); and 546 BIT STRING value field including y. 548 The key usage extension may optionally appear in a KEA certificate. 549 If a KEA certificate includes the keyUsage extension, only the fol- 550 lowing values may be asserted: 552 keyAgreement; 553 encipherOnly; and 554 decipherOnly. 556 If present, the keyUsage extension MUST assert keyAgreement and MAY 557 assert either encipherOnly and decipherOnly. The keyUsage extension 558 MUST NOT assert both encipherOnly and decipherOnly. 560 2.3.5 ECDSA and ECDH Keys 562 This section identifies the preferred OID and parameter encoding for 563 the inclusion of an ECDSA or ECDH public key in a certificate. The 564 Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 565 [X9.62]. ECDSA is the elliptic curve mathematical analog of the Dig- 566 ital Signature Algorithm [FIPS 186]. The Elliptic Curve Diffie Hell- 567 man (ECDH) algorithm is a key agreement algorithm defined in [X9.63]. 568 ECDH is the elliptic curve mathemetical analog of the Diffie-Hellman 569 key agreement algorithm as specified in [X9.42]. These specifica- 570 tions use the same OIDs and parameter encodings. The ASN.1 object 571 identifiers used to identify these public keys are defined in the 572 following arc: 574 ansi-X9-62 OBJECT IDENTIFIER ::= 575 { iso(1) member-body(2) us(840) 10045 } 577 When certificates contain an ECDSA or ECDH public key, the id-ecPub- 578 licKey algorithm identifier MUST be used. The id-ecPublicKey algo- 579 rithm identifier is defined as follows: 581 id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 } 583 id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } 585 This OID is used in public key certificates for both ECDSA signature 586 keys and ECDH encryption keys. The intended application for the key 587 may be indicated in the key usage field (see [RFC XXXX]). The use of 588 a single key for both signature and encryption purposes is not 589 recommended, but is not forbidden. 591 ECDSA and ECDH require use of certain parameters with the public key. 592 The parameters may be inherited from the issuer, implicitly included 593 through reference to a "named curve," or explicitly included in the 594 certificate. 596 ecpkParameters ::= CHOICE { 597 ecParameters ECParameters, 598 namedCurve OBJECT IDENTIFIER, 599 implicitlyCA NULL } 601 When the parameters are inherited, the parameters field shall contain 602 implictlyCA, which is the ASN.1 value NULL. When parameters are 603 specified by reference, the parameters field shall contain the named- 604 Curve choice, which is an object identifier. When the parameters are 605 explicitly included, they shall be encoded in the ASN.1 structure 606 ECParameters: 608 ECParameters ::= SEQUENCE { 609 version ECPVer, -- version is always 1 610 fieldID FieldID, -- identifies the finite field over 611 -- which the curve is defined 612 curve Curve, -- coefficients a and b of the 613 -- elliptic curve 614 base ECPoint, -- specifies the base point P 615 -- on the elliptic curve 616 order INTEGER, -- the order n of the base point 617 cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n 618 } 620 ECPVer ::= INTEGER {ecpVer1(1)} 622 Curve ::= SEQUENCE { 623 a FieldElement, 624 b FieldElement, 625 seed BIT STRING OPTIONAL } 627 FieldElement ::= OCTET STRING 629 ECPoint ::= OCTET STRING 631 The value of FieldElement shall be the octet string representation of 632 a field element following the conversion routine in [X9.62], Section 633 4.3.3. The value of ECPoint shall be the octet string representation 634 of an elliptic curve point following the conversion routine in 635 [X9.62], Section 4.3.6. Note that this octet string may represent an 636 elliptic curve point in compressed or uncompressed form. 638 Implementations that support elliptic curve according to this speci- 639 fication MUST support the uncompressed form and MAY support the com- 640 pressed form. 642 The components of type ECParameters have the following meanings: 644 version specifies the version number of the elliptic curve parame- 645 ters. It MUST have the value 1 (ecpVer1). 647 fieldID identifies the finite field over which the elliptic curve 648 is defined. Finite fields are represented by values of the parame- 649 terized type FieldID, constrained to the values of the objects 650 defined in the information object set FieldTypes. Additional 651 detail regarding fieldID is provided below. 653 curve specifies the coefficients a and b of the elliptic curve E. 654 Each coefficient shall be represented as a value of type FieldEle- 655 ment, an OCTET STRING. seed is an optional parameter used to 656 derive the coefficients of a randomly generated elliptic curve. 658 base specifies the base point P on the elliptic curve. The base 659 point shall be represented as a value of type ECPoint, an OCTET 660 STRING. 662 order specifies the order n of the base point. 664 cofactor is the integer h = #E(Fq)/n. This parameter is specified 665 as OPTIONAL. However, the cofactor MUST be included in ECDH pub- 666 lic key parameters. The cofactor is not required to support 667 ECDSA, except in parameter validation. The cofactor MAY be 668 included to support parameter validation for ECDSA keys. Parame- 669 ter validation is not required by this specification. 671 The AlgorithmIdentifier within subjectPublicKeyInfo is the only place 672 within a certificate where the parameters may be used. If the ellip- 673 tic curve parameters are specified as implicitlyCA in the subjectPub- 674 licKeyInfo AlgorithmIdentifier and the CA signed the subject certifi- 675 cate using ECDSA, then the certificate issuer's ECDSA parameters 676 apply to the subject's ECDSA key. If the elliptic curve parameters 677 are specified as implicitlyCA in the subjectPublicKeyInfo AlgorithmI- 678 dentifier and the CA signed the certificate using a signature algo- 679 rithm other than ECDSA, then clients MUST not make use of the ellip- 680 tic curve public key. 682 FieldID ::= SEQUENCE { 683 fieldType OBJECT IDENTIFIER, 684 parameters ANY DEFINED BY fieldType 685 } 686 FieldID is a SEQUENCE of two components, fieldType and parameters. 687 The fieldType contains an object identifier value that uniquely iden- 688 tifies the type contained in the parameters. 690 The object identifier id-fieldType specifies an arc containing the 691 object identifiers of each field type. It has the following value: 693 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 695 The object identifiers prime-field and characteristic-two-field name 696 the two kinds of fields defined in this Standard. They have the fol- 697 lowing values: 699 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 701 Prime-p ::= INTEGER -- Field size p (p in bits) 703 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 705 Characteristic-two ::= SEQUENCE { 706 m INTEGER, -- Field size 2^m 707 basis OBJECT IDENTIFIER, 708 parameters ANY DEFINED BY basis 709 } 711 The object identifier id-characteristic-two-basis specifies an arc 712 containing the object identifiers for each type of basis for the 713 characteristic-two finite fields. It has the following value: 715 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 716 characteristic-two-field basisType(1) } 718 The object identifiers gnBasis, tpBasis and ppBasis name the three 719 kinds of basis for characteristic-two finite fields defined by 720 [X9.62]. They have the following values: 722 gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 724 -- for gnBasis, the value of the parameters field is NULL 726 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 728 -- type of parameters field for tpBasis is Trinomial 730 Trinomial ::= INTEGER 732 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 733 -- type of parameters field for ppBasis is Pentanomial 735 Pentanomial ::= SEQUENCE { 736 k1 INTEGER, 737 k2 INTEGER, 738 k3 INTEGER 739 } 741 The elliptic curve public key (an ECPoint which is an OCTET STRING) 742 is mapped to a subjectPublicKey (a BIT STRING) as follows: the most 743 significant bit of the OCTET STRING becomes the most significant bit 744 of the BIT STRING, and the least significant bit of the OCTET STRING 745 becomes the least significant bit of the BIT STRING. Note that this 746 octet string may represent an elliptic curve point in compressed or 747 uncompressed form. Implementations that support elliptic curve 748 according to this specification MUST support the uncompressed form 749 and MAY support the compressed form. 751 If the keyUsage extension is present in an end entity certificate 752 which conveys an elliptic curve public key, any combination of the 753 following values MAY be present: 755 digitalSignature; 756 nonRepudiation; and 757 keyAgreement. 759 If the keyAgreement value is present, either of the following values 760 MAY be present: 762 encipherOnly; and 763 decipherOnly. 765 The keyUsage extension MUST NOT assert both encipherOnly and deci- 766 pherOnly. 768 If the keyUsage extension is present in a CA certificate which con- 769 veys an elliptic curve public key, any combination of the following 770 values MAY be present: 772 digitalSignature; 773 nonRepudiation; 774 keyAgreement; 775 keyCertSign; and 776 cRLSign. 778 As above, if the keyUsage extension asserts keyAgreement then it MAY 779 assert either encipherOnly and decipherOnly. However, this specifi- 780 cation RECOMMENDS that if keyCertSign or cRLSign is present, keyA- 781 greement, encipherOnly, and decipherOnly SHOULD NOT be present. 783 3 ASN.1 Module 785 PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6) 786 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 787 id-mod-pkix1-algorithms(17) } 789 DEFINITIONS EXPLICIT TAGS ::= BEGIN 791 -- EXPORTS All; 793 -- IMPORTS NONE; 795 ---- 796 ---- DSA Keys and Signatures 797 ---- 799 -- OID for DSA public key 801 id-dsa OBJECT IDENTIFIER ::= { 802 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 804 -- encoding for DSA public key 806 Dss-Parms ::= SEQUENCE { 807 p INTEGER, 808 q INTEGER, 809 g INTEGER } 811 -- OID for DSA signature generated with SHA-1 hash 813 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 814 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 816 -- encoding for DSA signature generated with SHA-1 hash 818 Dss-Sig-Value ::= SEQUENCE { 819 r INTEGER, 820 s INTEGER } 821 ---- 822 ---- RSA Keys and Signatures 823 ---- 824 ---- 826 -- arc for RSA public key and RSA signature OIDs 827 pkcs-1 OBJECT IDENTIFIER ::= { 828 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 830 -- OID for RSA public keys 832 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 834 -- OID for RSA signature generated with MD2 hash 836 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 838 -- OID for RSA signature generated with MD5 hash 840 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 842 -- OID for RSA signature generated with SHA-1 hash 844 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 846 ---- 847 ---- Diffie-Hellman Keys 848 ---- 849 ---- 851 dhpublicnumber OBJECT IDENTIFIER ::= { 852 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 854 DomainParameters ::= SEQUENCE { 855 p INTEGER, -- odd prime, p=jq +1 856 g INTEGER, -- generator, g 857 q INTEGER, -- factor of p-1 858 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 859 validationParms ValidationParms OPTIONAL } 861 ValidationParms ::= SEQUENCE { 862 seed BIT STRING, 863 pgenCounter INTEGER } 865 ---- 866 ---- KEA Keys 867 ---- 868 ---- 870 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= 871 { 2 16 840 1 101 2 1 1 22 } 873 KEA-Parms-Id ::= OCTET STRING 875 ---- 876 ---- Elliptic Curve Keys, Signatures, and Curves 877 ---- 878 ---- 880 ansi-X9-62 OBJECT IDENTIFIER ::= { 881 iso(1) member-body(2) us(840) 10045 } 883 FieldID ::= SEQUENCE { -- Finite field 884 fieldType OBJECT IDENTIFIER, 885 parameters ANY DEFINED BY fieldType 886 } 888 -- 889 -- ECDSA signatures 890 -- 891 -- 893 -- Arc for ECDSA signature OIDS 895 id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } 897 -- OID for ECDSA signatures with SHA-1 899 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } 901 -- OID for an elliptic curve signature 902 -- format for the value of an ECDSA signature value 904 ECDSA-Sig-Value ::= SEQUENCE { 905 r INTEGER, 906 s INTEGER 907 } 909 -- 910 -- Elliptic Curve Keys 911 -- 912 -- 914 -- recognized field type OIDs are defined in the following arc 916 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 918 -- where fieldType is prime-field, the parameters are of type Prime-p 920 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 922 Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime 923 -- where fieldType is characteristic-two-field, the parameters are 924 -- of type Characteristic-two 926 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 928 Characteristic-two ::= SEQUENCE { 929 m INTEGER, -- Field size 2^m 930 basis OBJECT IDENTIFIER, 931 parameters ANY DEFINED BY basis 932 } 934 -- recognized basis type OIDs are defined in the following arc 936 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 937 characteristic-two-field basisType(3) } 939 -- gnbasis is identified by OID gnBasis and indicates 940 -- parameters are NULL 942 gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 944 -- parameters for this basis are NULL 946 -- trinomial basis is identified by OID tpBasis and indicates 947 -- parameters of type Pentanomial 949 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 951 -- Trinomial basis representation of F2^m 952 -- Integer k for reduction polynomial xm + xk + 1 953 -- 955 Trinomial ::= INTEGER 957 -- for pentanomial basis is identified by OID ppBasis and indicates 958 -- parameters of type Pentanomial 960 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 962 Pentanomial ::= SEQUENCE { 963 -- 964 -- Pentanomial basis representation of F2^m 965 -- reduction polynomial integers k1, k2, k3 966 -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1 967 -- 968 k1 INTEGER, 969 k2 INTEGER, 970 k3 INTEGER 972 } 974 -- The object identifiers gnBasis, tpBasis and ppBasis name 975 -- three kinds of basis for characteristic-two finite fields 977 FieldElement ::= OCTET STRING -- Finite field element 979 ECPoint ::= OCTET STRING -- Elliptic curve point 981 -- Elliptic Curve parameters may be specfied explicitly, 982 -- specified implicitly through a "named curve", or 983 -- inherited from the CA 985 ecpkParameters ::= CHOICE { 986 ecParameters ECParameters, 987 namedCurve OBJECT IDENTIFIER, 988 implicitlyCA NULL 989 } 991 ECParameters ::= SEQUENCE { -- Elliptic curve parameters 992 version ECPVer, 993 fieldID FieldID, 994 curve Curve, 995 base ECPoint, -- Base point G 996 order INTEGER, -- Order n of the base point 997 cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n 998 } 1000 ECPVer ::= INTEGER {ecpVer1(1)} 1002 Curve ::= SEQUENCE { 1003 a FieldElement, -- Elliptic curve coefficient a 1004 b FieldElement, -- Elliptic curve coefficient b 1005 seed BIT STRING OPTIONAL 1006 } 1007 id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) } 1009 id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } 1011 -- Named Elliptic Curves 1012 -- 1013 -- Standards bodies may define OIDs to represent common 1014 -- elliptic curve parameters. Users are encouraged 1015 -- to consult relevant standards and specifications to 1016 -- determine which OIDs (if any) are appropriate for their 1017 -- applications. 1019 -- The following OIDS are defined in ANSI X9.62. 1021 ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) } 1023 c-TwoCurve OBJECT IDENTIFIER ::= { 1024 ellipticCurve characteristicTwo(0) } 1026 primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) } 1028 c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 } 1029 c2pnb163v2 OBJECT IDENTIFIER ::= { c-TwoCurve 2 } 1030 c2pnb163v3 OBJECT IDENTIFIER ::= { c-TwoCurve 3 } 1031 c2pnb176w1 OBJECT IDENTIFIER ::= { c-TwoCurve 4 } 1032 c2tnb191v1 OBJECT IDENTIFIER ::= { c-TwoCurve 5 } 1033 c2tnb191v2 OBJECT IDENTIFIER ::= { c-TwoCurve 6 } 1034 c2tnb191v3 OBJECT IDENTIFIER ::= { c-TwoCurve 7 } 1035 c2onb191v4 OBJECT IDENTIFIER ::= { c-TwoCurve 8 } 1036 c2onb191v5 OBJECT IDENTIFIER ::= { c-TwoCurve 9 } 1037 c2pnb208w1 OBJECT IDENTIFIER ::= { c-TwoCurve 10 } 1038 c2tnb239v1 OBJECT IDENTIFIER ::= { c-TwoCurve 11 } 1039 c2tnb239v2 OBJECT IDENTIFIER ::= { c-TwoCurve 12 } 1040 c2tnb239v3 OBJECT IDENTIFIER ::= { c-TwoCurve 13 } 1041 c2onb239v4 OBJECT IDENTIFIER ::= { c-TwoCurve 14 } 1042 c2onb239v5 OBJECT IDENTIFIER ::= { c-TwoCurve 15 } 1043 c2pnb272w1 OBJECT IDENTIFIER ::= { c-TwoCurve 16 } 1044 c2pnb304w1 OBJECT IDENTIFIER ::= { c-TwoCurve 17 } 1045 c2tnb359v1 OBJECT IDENTIFIER ::= { c-TwoCurve 18 } 1046 c2pnb368w1 OBJECT IDENTIFIER ::= { c-TwoCurve 19 } 1047 c2tnb431r1 OBJECT IDENTIFIER ::= { c-TwoCurve 20 } 1049 prime192v1 OBJECT IDENTIFIER ::= { primeCurve 1 } 1050 prime192v2 OBJECT IDENTIFIER ::= { primeCurve 2 } 1051 prime192v3 OBJECT IDENTIFIER ::= { primeCurve 3 } 1052 prime239v1 OBJECT IDENTIFIER ::= { primeCurve 4 } 1053 prime239v2 OBJECT IDENTIFIER ::= { primeCurve 5 } 1054 prime239v3 OBJECT IDENTIFIER ::= { primeCurve 6 } 1055 prime256v1 OBJECT IDENTIFIER ::= { primeCurve 7 } 1057 END 1059 4 References 1061 [FIPS 180-1] Federal Information Processing Standards Publication 1062 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 1063 [Supersedes FIPS PUB 180 dated 11 May 1993.] 1065 [FIPS 186-2] Federal Information Processing Standards Publication 1066 (FIPS PUB) 186, Digital Signature Standard, 27 January 1067 2000. [Supersedes FIPS PUB 186-1 dated 15 December 1998.] 1069 [P1363] IEEE P1363, "Standard Specifications for Public-Key 1070 Cryptography", 2001. 1072 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 1073 MD2 is not collision free," Presented at Selected Areas in 1074 Cryptography '95, May 1995. 1076 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 1077 facilities", November 1987. 1079 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 1080 RSA Laboratories, April 1992. 1082 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 1083 MIT and RSA Data Security, April 1992. 1085 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 1086 Mail: Part II: Certificate-Based Key Management," RFC 1087 1422, BBN Communications, February 1993. 1089 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 1090 Mail: Part III: Algorithms, Modes, and Identifiers," 1091 RFC 1423, Trusted Information Systems, February 1993. 1093 [RFC 2119] S. Bradner, "Key Words for Use in RFCs to Indicate 1094 Requirement Levels", RFC 2219, Harvard University, March 1095 1997. 1097 [RFC 2313] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", 1098 RFC 2313, March 1998. 1100 [RFC 2459] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509 1101 Public Key Infrastructure: Certificate and CRL Profile", 1102 January, 1999. 1104 [SDN.701r] SDN.701, "Message Security Protocol 4.0", Revision A 1105 1997-02-06. 1107 [X.208] CCITT Recommendation X.208: Specification of Abstract 1108 Syntax Notation One (ASN.1), 1988. 1110 [X9.42] ANSI X9.42-2000, "Public Key Cryptography for The Financial 1111 Services Industry: Agreement of Symmetric Keys Using 1112 Discrete Logarithm Cryptography", December, 1999. 1114 [X9.62] X9.62-1998, "Public Key Cryptography For The Financial 1115 Services Industry: The Elliptic Curve Digital Signature 1116 Algorithm (ECDSA)", January 7, 1999. 1118 [X9.63] ANSI X9.63-2001, "Public Key Cryptography For The Financial 1119 Services Industry: Key Agreement and Key Transport 1120 Using Elliptic Curve Cryptography" (Working Draft), 1121 May 8, 2001. 1123 5 Security Considerations 1125 This specification does not constrain the size of public keys or 1126 their parameters for use in the Internet PKI. However, the key size 1127 selected impacts the strength achieved when implementing crypto- 1128 graphic services. Selection of appropriate key sizes is critical to 1129 implementing appropriate security. 1131 This specification does not identify particular elliptic curves for 1132 use in the Internet PKI. However, the particular curve selected 1133 impact the the strength of the digital signatures. Some curves are 1134 cryptographically stronger than others! 1136 In general, use of "well-known" curves, such as the "named curves" 1137 from ANSI X9.62 is a sound strategy. For additional information, 1138 refer to X9.62 Appendix H.1.3, "Key Length Considerations" and 1139 Appendix A.1, "Avoiding Cryptographically Weak Keys". 1141 This specification supplements RFC XXXX. The security considerations 1142 section of that document applies to this specification as well. 1144 6 Intellectual Property Rights 1146 The IETF has been notified of intellectual property rights claimed in 1147 regard to some or all of the specification contained in this docu- 1148 ment. For more information consult the online list of claimed 1149 rights. 1151 The IETF takes no position regarding the validity or scope of any 1152 intellectual property or other rights that might be claimed to per- 1153 tain to the implementation or use of the technology described in this 1154 document or the extent to which any license under such rights might 1155 or might not be available; neither does it represent that it has made 1156 any effort to identify any such rights. Information on the IETF's 1157 procedures with respect to rights in standards-track and standards- 1158 related documentation can be found in BCP-11. Copies of claims of 1159 rights made available for publication and any assurances of licenses 1160 to be made available, or the result of an attempt made to obtain a 1161 general license or permission for the use of such proprietary rights 1162 by implementors or users of this specification can be obtained from 1163 the IETF Secretariat. 1165 7 Author Addresses: 1167 Larry Bassham 1168 NIST 1169 100 Bureau Drive, Stop 8930 1170 Gaithersburg, MD 20899-8930 1171 USA 1172 lbassham@nist.gov 1174 Russell Housley 1175 RSA Laboratories 1176 918 Spring Knoll Drive 1177 Herndon, VA 20170 1178 USA 1179 rhousley@rsasecurity.com 1181 Tim Polk 1182 NIST 1183 100 Bureau Drive, Stop 8930 1184 Gaithersburg, MD 20899-8930 1185 USA 1186 tim.polk@nist.gov 1188 8 Full Copyright Statement 1190 Copyright (C) The Internet Society (date). All Rights Reserved. 1192 This document and translations of it may be copied and furnished to 1193 others, and derivative works that comment on or otherwise explain it 1194 or assist in its implementation may be prepared, copied, published 1195 and distributed, in whole or in part, without restriction of any 1196 kind, provided that the above copyright notice and this paragraph are 1197 included on all such copies and derivative works. In addition, the 1198 ASN.1 modules presented in Appendices A and B may be used in whole or 1199 in part without inclusion of the copyright notice. However, this 1200 document itself may not be modified in any way, such as by removing 1201 the copyright notice or references to the Internet Society or other 1202 Internet organizations, except as needed for the purpose of develop- 1203 ing Internet standards in which case the procedures for copyrights 1204 defined in the Internet Standards process shall be followed, or as 1205 required to translate it into languages other than English. 1207 The limited permissions granted above are perpetual and will not be 1208 revoked by the Internet Society or its successors or assigns. This 1209 document and the information contained herein is provided on an "AS 1210 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1211 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1212 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1213 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1214 OR FITNESS FOR A PARTICULAR PURPOSE.