idnits 2.17.1 draft-ietf-pkix-ipki-ecdsa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-pkix-ipki-ecdsa-01', but the file name used is 'draft-ietf-pkix-ipki-ecdsa-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 917 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 336: '... seed BIT STRING OPTIONAL...' RFC 2119 keyword, line 421: '...D.&Type({IOSet}{@fieldType}) OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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? 'P1363' on line 647 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group L. Bassham 3 (NIST) 5 Internet Draft D. Johnson 6 (Certicom) 8 expires in six months W. Polk 9 (NIST) 11 November 21, 12 1997 14 Internet X.509 Public Key Infrastructure 16 Representation of Elliptic Curve Digital Signature Algorithm 18 (ECDSA) Keys and Signatures in Internet X.509 Public Key 20 Infrastructure Certificates 22 < 24 Status of this Memo 26 This document is an Internet-Draft. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 32 working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months 37 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet- Drafts as reference 41 material or to cite them other than as "work in progress." 43 To learn the current status of any Internet-Draft, please check the 45 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 47 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 49 munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 51 ftp.isi.edu (US West Coast). 53 Abstract 55 This is the first draft of a profile for specification of Elliptic 56 Curve Digital Signature Algorithm (ECDSA) keys in Internet Public Key 57 Infrastructure X.509 certificates. Please send comments on this 58 document to the ietf-pkix@tandem.com mail list. 60 1 Executive Summary 62 This specification contains guidance on the use of the Internet 64 Public Key Infrastructure certificates to convey Elliptic Curve 66 Digital Signature Algorithm (ECDSA) keys. This specification is an 68 addendum to RFC xxxx, "Internet Public Key Infrastructure: 70 Bassham, Johnson & Polk [Page 71 1] 72 1997 74 Certificate and CRL Profile". Implementations of this specification 76 must also conform to RFC xxxx. Implementations of this specification 78 are not required to conform to other parts from that series. 80 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the 82 elliptic curve analog of the Digital Signature Algorithm (DSA). 83 This 85 specification profiles the format and semantics of fields in X.509 86 V3 88 certificates containing ECDSA keys. The specification addresses the 90 subjectPublicKeyInfo field and the keyUsage extension. 92 2 Requirements and Assumptions 94 The goal is to augment the X.509 certificate profile presented in 96 Part 1 to facilitate the use and management of ECDSA keys for those 98 communities which use this algorithm. 100 2.1 Communication and Topology 102 This profile, as presented in Part 1 and augmented by this 104 specification, supports users without high bandwidth, real-time IP 106 connectivity, or high connection availability. In addition, the 108 profile allows for the presence of firewall or other filtered 110 communication. 112 This profile does not assume the deployment of an X.500 Directory 114 system. The profile does not prohibit the use of an X.500 115 Directory, 117 but other means of distributing certificates and certificate 119 revocation lists (CRLs) are supported. 121 2.2 Acceptability Criteria 123 The goal of the Internet Public Key Infrastructure (PKI) is to meet 125 the needs of deterministic, automated identification, 126 authentication, 128 access control, and authorization functions. Support for these 130 services determines the attributes contained in the certificate as 132 well as the ancillary control information in the certificate such as 134 policy data and certification path constraints. 136 The goal of this document is to profile ECDSA certificates, 138 specifying the contents and semantics of attributes which were not 140 fully specified by Part 1. If not specifically addressed by this 142 document, the contents and semantics of the fields and extensions 144 must be as described in Part 1. 146 2.3 User Expectations 148 Users of the Internet PKI are people and processes who use client 150 software and are the subjects named in certificates. These uses 152 Bassham, Johnson & Polk [Page 153 2] 154 1997 156 include readers and writers of electronic mail, the clients for WWW 158 browsers, WWW servers, and the key manager for IPSEC within a 159 router. 161 This profile recognizes the limitations of the platforms these users 163 employ and the sophistication/attentiveness of the users themselves. 165 This manifests itself in minimal user configuration responsibility 167 (e.g., root keys, rules), explicit platform usage constraints within 169 the certificate, certification path constraints which shield the 170 user 172 from many malicious actions, and applications which sensibly 173 automate 175 validation functions. 177 2.4 Administrator Expectations 179 As with users, the Internet PKI profile is structured to support the 181 individuals who generally operate Certification Authorities (CAs). 183 Providing administrators with unbounded choices increases the 184 chances 186 that a subtle CA administrator mistake will result in broad 188 compromise or unnecessarily limit interoperability. This profile 190 defines the object identifiers and data formats that must be 192 supported to interpret ECDSA public keys. 194 3 ECDSA Algorithm Support 196 This section describes object identifiers and data formats which may 198 be used with PKIX certificate profile to describe X.509 certificates 200 containing a ECDSA public key or signed with ECDSA. Conforming CAs 202 are required to use the object identifiers and data formats when 204 issuing ECDSA certificates. Conforming applications shall recognize 206 the object identifiers and process the data formats when processing 208 such certificates. 210 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 212 the draft ANSI X9.62 standard [X9.62]. The ASN.1 object identifiers 214 used to identify the ECDSA algorithm are defined in the following 216 arc: 218 ansi-X9-62 OBJECT IDENTIFIER ::= 220 { iso(1) member-body(2) us(840) 10045 } 222 3.1 Subject Public Key Info 224 The certificate identifies the ECDSA algorithm, conveys optional 226 parameters, and specifies the ECDSA public key in the 228 subjectPublicKeyInfo field. The subjectPublicKeyInfo field is a 230 SEQUENCE of an algorithm identifier and the subjectPublicKey field. 232 The certificate indicates the algorithm through an algorithm 234 identifier. This algorithm identifier consists of an object 236 identifier (OID) and optional associated parameters. Section 3.1.1 238 Bassham, Johnson & Polk [Page 239 3] 240 1997 242 identifies the preferred OID and parameters for the ECDSA algorithm. 244 Conforming CAs shall use the identified OID when issuing 245 certificates 247 containing public keys for the ECDSA algorithm. Conforming 249 applications supporting the ECDSA algorithm shall, at a minimum, 251 recognize the OID identified in section 3.1.1. 253 The certificate conveys the ECDSA public key through the 255 subjectPublicKey field. This subjectPublicKey field is a BIT 256 STRING. 258 Section 3.1.2 specifies the method for encoding a ECDSA public key 259 as 261 a BIT STRING. Conforming CAs shall encode the ECDSA public key as 263 described in Section 3.1.2 when issuing certificates containing 265 public keys for the ECDSA algorithm. Conforming applications 267 supporting the ECDSA algorithm shall decode the subjectPublicKey as 269 described in section 3.1.2 when the algorithm identifier is the one 271 presented in 3.1.1. 273 3.1.1 Algorithm Identifier and Parameters 275 When certificates contain an ECDSA public key, the id-ecPublicKey 277 algorithm identifier shall be used. The id-ecPublicKey algorithm 279 identifier is defined as follows: 281 id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 } 283 id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 } 285 ECDSA requires use of certain parameters with the public key. The 287 parameters may be included in the certificate using the following 289 ASN.1 structure: 291 ECParameters ::= SEQUENCE { 293 version INTEGER { ecpVer1(1) } (ecpVer1), 295 -- version is always 1 297 fieldID FieldID { {FieldTypes} }, 299 -- identifies the finite field over 301 -- which the curve is defined 303 curve Curve, -- coefficients a and b of the 305 -- elliptic curve 307 base ECPoint, -- specifies the base point P 309 -- on the elliptic curve 311 order INTEGER, -- the order n of the base point 313 cofactor INTEGER, 315 ... } 317 FieldElement ::= OCTET STRING 319 Bassham, Johnson & Polk [Page 320 4] 321 1997 323 The value of FieldElement shall be the octet string representation 324 of 326 a field element following the conversion routine in [X9.62, Section 328 4.3.1] 330 Curve ::= SEQUENCE { 332 a FieldElement, 334 b FieldElement, 336 seed BIT STRING OPTIONAL 338 } 340 ECPoint ::= OCTET STRING 342 The value of ECPoint shall be the octet string representation of an 344 elliptic curve point following the conversion routine in [X9.62, 346 Section 4.4.3.b] 348 The components of type ECParameters have the following meanings: 350 * version specifies the version number of the elliptic curve 352 parameters. It shall have the value 1 for this version of the 354 Standard. The notation above creates an INTEGER named ecpVer1 and 356 gives it a value of one. It is used to constrain version to a single 358 value. 360 * fieldID identifies the finite field over which the elliptic curve 362 is defined. Finite fields are represented by values of the 364 parameterized type FieldID, constrained to the values of the objects 366 defined in the information object set FieldTypes. Additional detail 368 regarding fieldID is provided below. 370 * curve specifies the coefficients a and b of the elliptic curve E. 372 Each coefficient shall be represented as a value of type 374 FieldElement, an OCTET STRING. seed is an optional parameter used to 376 derive the coefficients of a randomly generated elliptic curve. 378 * base specifies the base point P on the elliptic curve. The base 380 point shall be represented as a value of type ECPoint, an OCTET 382 STRING. 384 * order specifies the order n of the base point. 386 * cofactor is the integer h = #E(Fq)/n. Note: This parameter is not 388 used in ECDSA, except in parameter validation. It is included for 390 compatibility with Elliptic Curve Key Agreement public key 392 parameters. 394 The AlgorithmIdentifier within subjectPublicKeyInfo is the only 395 place 397 within a certificate where the parameters may be used. If the ECDSA 399 Bassham, Johnson & Polk [Page 400 5] 401 1997 403 algorithm parameters are absent from the subjectPublicKeyInfo 405 AlgorithmIdentifier and the CA signed the subject certificate using 407 ECDSA, then the certificate issuer's ECDSA parameters apply to the 409 subject's ECDSA key. If the ECDSA algorithm parameters are absent 411 from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed 413 the certificate using a signature algorithm other than ECDSA, then 415 clients shall not validate the certificate. 417 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 419 fieldType FIELD-ID.&id({IOSet}), 421 parameters FIELD-ID.&Type({IOSet}{@fieldType}) OPTIONAL 423 } 425 FieldTypes FIELD-ID ::= { 427 { Prime-p IDENTIFIED BY prime-field } | 429 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 431 ... 433 } 435 FIELD-ID ::= TYPE-IDENTIFIER 437 FieldID is a parameterized type composed of two components, 438 fieldType 440 and parameters. These components are specified by the fields &id 441 and 443 &Type, which form a template for defining sets of information 445 objects, instances of the class FIELD-ID. This class is based on the 447 useful information object class TYPE-IDENTIFIER, described in X.681 449 Annex A. In an instance of FieldID, "fieldType" will contain an 451 object identifier value that uniquely identifies the type contained 453 in "parameters". The effect of referencing "fieldType" in both 455 components of the fieldID sequence is to tightly bind the object 457 identifier and its type. 459 The information object set FieldTypes is used as the single 460 parameter 462 in a reference to type FieldID. FieldTypes contains two objects 464 followed by the extension marker ("..."). Each object, which 466 represents a finite field, contains a unique object identifier and 468 its associated type. The values of these objects define all of the 470 valid values that may appear in an instance of fieldID. The 471 extension 473 marker allows backward compatibility with future versions of this 475 standard which may define objects to represent additional kinds of 477 finite fields. 479 The object identifier id-fieldType represents the root of a tree 481 containing the object identifiers of each field type. It has the 483 following value: 485 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 487 The object identifiers prime-field and characteristic-two-field name 489 Bassham, Johnson & Polk [Page 490 6] 491 1997 493 the two kinds of fields defined in this Standard. They have the 495 following values: 497 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 499 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 501 Prime-p ::= INTEGER -- Field size p (p in bits) 503 Characteristic-two ::= SEQUENCE { 505 m INTEGER, -- Field size 2^m (m in bits) 507 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 509 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) 511 } 513 BasisTypes CHARACTERISTIC-TWO::= { 515 { NULL IDENTIFIED BY onBasis } | 517 { Trinomial IDENTIFIED BY tpBasis } | 519 { Pentanomial IDENTIFIED BY ppBasis }, 521 ... 523 } 525 Trinomial ::= INTEGER 527 Pentanomial ::= SEQUENCE { 529 k1 INTEGER, 531 k2 INTEGER, 533 k3 INTEGER 535 } 537 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 539 The object identifier id-characteristic-two-basis represents the 540 root 542 of a tree containing the object identifiers for each type of basis 544 for the characteristic-two finite fields. It has the following 545 value: 547 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 549 characteristic-two-field basisType(1) } 551 The object identifiers onBasis, tpBasis and ppBasis name the three 553 kinds of basis for characteristic-two finite fields defined by 555 [X9.62]. They have the following values: 557 onBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 559 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 561 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 563 Bassham, Johnson & Polk [Page 564 7] 565 1997 567 3.1.2 Encoding of ECDSA Public Keys 569 The elliptic curve public key (an ECPoint which is an OCTET STRING) 571 is mapped to a subjectPublicKey (a BIT STRING) as follows: the most 573 significant bit of the OCTET STRING becomes the most significant bit 575 of the BIT STRING, etc.; the least significant bit of the OCTET 577 STRING becomes the least significant bit of the BIT STRING. 579 3.1.3 Key Usage Extension in ECDSA certificates 581 The key usage extension may optionally appear in certificates which 583 convey an ECDSA public key. If a certificate containing an ECDSA 585 public key includes the keyUsage extension, only the following 586 values 588 may be asserted: 590 digitalSignature; 592 nonRepudiation; 594 keyCertSign; and 596 cRLSign. 598 The keyCertSign and cRLSign values may only be asserted if the 600 basicConstraints extension is present and cA is TRUE. 602 3.2 Representation of ECDSA Signatures 604 When used to sign certificates, CRLs, or PKI messages, the ECDSA 606 shall be used with the SHA-1 hash algorithm. The ASN.1 object 608 identifier used to identify the ECDSA algorithm with SHA-1 shall be: 610 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-X9-62 1 } 612 When the ecdsa-with-SHA1 algorithm identifier is used in the SIGNED 614 parameterized TYPE (e.g., in the signature on a certificate or CRL) 616 it shall have NULL parameters. The ECDSA parameters in the 618 certificate of the issuer shall apply to the verification of the 620 signature. When signing, the ECDSA algorithm generates two values. 622 These values are commonly referred to as r and s. To easily 623 transfer 625 these two values as one signature, they shall be ASN.1 encoded using 627 the following ASN.1 structure: 629 Ecdsa-Sig-Value ::= SEQUENCE { 631 r INTEGER, 633 s INTEGER } 635 References 637 Bassham, Johnson & Polk [Page 638 8] 639 1997 641 [X9.62] X9.62-199x, "Public Key Cryptography For The Financial 643 Services Industry: The Elliptic Curve Digital Signature 645 Algorithm (ECDSA)" November 17, 1997. 647 [P1363] IEEE P1363, "Standard for Public-Key Cryptography", draft 649 standard, 1997. 651 [RFC xxxx] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509 653 Public Key Infrastructure: Certificate and CRL Profile", 655 October 28, 1997. 657 Patent Statements 659 To be added. 661 Security Considerations 663 This entire memo is about security mechanisms. 665 Author Addresses: 667 Larry Bassham 669 NIST 671 Building 820, Room 426 673 Gaithersburg, MD 20899 675 USA 677 lbassham@nist.gov 679 Don Johnson 681 Certicom 683 7684 Knightshayes Drive 685 Manassas, VA 20111 687 djohnson@certicom.com 689 Tim Polk 691 NIST 693 Building 820, Room 426 695 Gaithersburg, MD 20899 697 USA 699 wpolk@nist.gov 701 Bassham, Johnson & Polk [Page 702 9]