idnits 2.17.00 (12 Aug 2021) /tmp/idnits16752/draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 196. -- Found old boilerplate from RFC 3978, Section 5.5 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 218. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (January 2005) is 6328 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '7' on line 85 == Unused Reference: 'N5' is defined on line 155, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'N3' -- Possible downref: Non-RFC (?) normative reference: ref. 'N4' -- Possible downref: Non-RFC (?) normative reference: ref. 'N5' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley 3 Internet-Draft Vigil Security 4 January 2005 6 Additional Algorithms and Identifiers 7 for use of Elliptic Curve Cryptography with PKIX 8 (Explicit Identification of One-Way Hash Functions) 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Dan Brown from Certicom has submitted a specification for Additional 37 Algorithms and Identifiers for use of Elliptic Curve Cryptography 38 with PKIX. This document proposes a different approach for 39 identifying the one-way hash function used with the ECDSA signature 40 algorithm. 42 1. Introduction 44 RFC 3279 [N1] specifies the conventions for using many algorithms 45 with certificates and CRLs. When ECDSA is used with SHA-1, RFC 3279 46 says that the following object identifier ought to be employed: 48 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 } 50 Dan Brown from Certicom has submitted a specification for Additional 51 Algorithms and Identifiers for use of Elliptic Curve Cryptography 52 with PKIX [I1]. In his document, Dan proposes a different approach 53 for identifying the one-way hash function used with the ECDSA 54 signature algorithm. 56 The following new object identifier identifies the one-way hash 57 function is the one recommended for the public key size: 59 ecdsa-with-Recommended OBJECT IDENTIFIER ::= { id-ecSigType recommended(2) } 61 In this case, the recommended one-way hash functions are given in the 62 draft revision of X9.62 [I2]. The appropriate one-way has function 63 is selected from SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The 64 recommended one has the largest bit size that does not require bit 65 truncation during the signing process. Bit truncation occurs when 66 the one-way hash function output bit length is greater than the bit 67 length of n, the order of the base point G. 69 This approach leads to potential ambiguity in the future. The 70 concern is that additional one-way hash functions will be added to 71 the "approved" set. 73 The alternative is to explicitly identify the one-way hash function 74 that is employed with ECDSA. 76 1.1. Conventions Used In This Document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [N2]. 82 1.2. Abstract Syntax Notation 84 All X.509 certificate [N3] extensions are defined using ASN.1 85 [N4][7]. 87 2. ECDSA with Explicit Identification of the One-Way Hash Function 89 To avoid potential ambiguity, this specification provides algorithm 90 identifiers for ECDSA with the following one-way hash functions: 91 SHA-224, SHA-256, SHA-384, and SHA-512. Note that the algorithm 92 identifier for ECDSA with SHA-1 is already provided in RFC 3279 [N1]. 94 These algorithm identifiers have already been assigned by ANSI X9F1. 95 They are: 97 ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 } 99 id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } 101 id-ecdsa-with-SHA2 OBJECT IDENTIFIER ::= {id-ecSigType 3} 103 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 1} 104 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 2} 105 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 3} 106 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 4} 108 3. Security Considerations 110 This specification does not constrain the size of public keys or 111 their parameters for use in the Internet PKI. However, the key size 112 selected impacts the strength achieved when implementing 113 cryptographic services. Selection of appropriate key sizes is 114 critical to implementing appropriate security. 116 This specification does not identify particular elliptic curves for 117 use in the Internet PKI. However, the particular curve selected 118 impact the strength of the digital signatures. Some curves are 119 cryptographically stronger than others! 121 In general, use of "well-known" curves, such as the "named curves" 122 from ANSI X9.62 [I2], is a sound strategy. For additional 123 information, refer to X9.62 Appendix H.1.3, "Key Length 124 Considerations" and Appendix A.1, "Avoiding Cryptographically Weak 125 Keys". 127 4. IANA Considerations 129 Certificate extensions and extended key usage values are identified 130 by object identifiers (OIDs). The OIDs used in this document are 131 copied from the draft revision to X9.62 [I2]. These OIDs were 132 assigned by ANSI X9F1. No further action by the IANA is necessary 133 for this document or any anticipated updates. 135 5. References 137 Normative and informative references are provided. 139 5.1. Normative References 141 [N1] Polk, W., Housley, R., and L. Bassham, "Algorithms and 142 Identifiers for the Internet X.509 Public Key Infrastructure 143 Certificate and Certificate Revocation List (CRL) Profile", 144 RFC 3279, April 2002. 146 [N2] Bradner, S., "Key words for use in RFCs to Indicate 147 Requirement Levels", BCP 14, RFC 2119, March 1997. 149 [N3] ITU-T. Recommendation X.509: The Directory - Authentication 150 Framework. 2000. 152 [N4] CCITT. Recommendation X.208: Specification of Abstract 153 Syntax Notation One (ASN.1). 1988. 155 [N5] CCITT. Recommendation X.209: Specification of Basic Encoding 156 Rules for Abstract Syntax Notation One (ASN.1). 1988. 158 5.2. Informative References 160 [I1] Brown, D., "Additional Algorithms and Identifiers for use of 161 Elliptic Curve Cryptography with PKIX", Internet-Draft, 162 July 2004, work in progress. 163 165 [I2] American National Standard for Financial Services. ANSI 166 X9.62-1998, Public Key Cryptography for the Financial Services 167 Industry: The Elliptic Curve Digital Signature Algorithm. 1998. 168 (An update is in the works.) 170 6. ASN.1 Module 172 ECDSA-Algorithm-Identifiers 173 { TBD } 175 DEFINITIONS IMPLICIT TAGS ::= 176 BEGIN 178 ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 } 180 id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) } 182 id-ecdsa-with-SHA2 OBJECT IDENTIFIER ::= {id-ecSigType 3} 184 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 1} 185 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 2} 186 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 3} 187 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 4} 189 END 191 7. IPR Considerations 193 By submitting this Internet-Draft, I certify that any applicable 194 patent or other IPR claims of which I am aware have been disclosed, 195 or will be disclosed, and any of which I become aware will be 196 disclosed, in accordance with RFC 3668. 198 The IETF takes no position regarding the validity or scope of any 199 Intellectual Property Rights or other rights that might be claimed to 200 pertain to the implementation or use of the technology described in 201 this document or the extent to which any license under such rights 202 might or might not be available; nor does it represent that it has 203 made any independent effort to identify any such rights. Information 204 on the procedures with respect to rights in RFC documents can be 205 found in BCP 78 and BCP 79. 207 Copies of IPR disclosures made to the IETF Secretariat and any 208 assurances of licenses to be made available, or the result of an 209 attempt made to obtain a general license or permission for the use of 210 such proprietary rights by implementers or users of this 211 specification can be obtained from the IETF on-line IPR repository at 212 http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights that may cover technology that may be required to implement 217 this standard. Please address the information to the IETF at ietf- 218 ipr@ietf.org. 220 8. Author's Address 222 Russell Housley 223 Vigil Security, LLC 224 918 Spring Knoll Drive 225 Herndon, VA 20170 227 housley@vigilsec.com 229 9. Full Copyright Statement 231 Copyright (C) The Internet Society (2005). This document is subject 232 to the rights, licenses and restrictions contained in BCP 78, and 233 except as set forth therein, the authors retain all their rights. 235 This document and translations of it may be copied and furnished to 236 others, and derivative works that comment on or otherwise explain it 237 or assist in its implementation may be prepared, copied, published 238 and distributed, in whole or in part, without restriction of any 239 kind, provided that the above copyright notice and this paragraph are 240 included on all such copies and derivative works. However, this 241 document itself may not be modified in any way, such as by removing 242 the copyright notice or references to the Internet Society or other 243 Internet organizations, except as needed for the purpose of 244 developing Internet standards in which case the procedures for 245 copyrights defined in the Internet Standards process must be 246 followed, or as required to translate it into languages other than 247 English. 249 This document and the information contained herein are provided on an 250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 252 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 253 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 254 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.