idnits 2.17.00 (12 Aug 2021) /tmp/idnits1278/draft-blake-wilson-xmldsig-ecdsa-02.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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 97: '...The XML namespace [XML-ns] URI that MUST be used by implementations...' RFC 2119 keyword, line 131: '...finition of the KeyValue schema SHOULD...' RFC 2119 keyword, line 149: '...efinition of the entity Key.ANY SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (20 March 2001) is 7731 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) == Missing Reference: 'FIPS186-2' is mentioned on line 73, but not defined == Missing Reference: 'XML-Schema' is mentioned on line 105, but not defined == Missing Reference: 'NIST-ECC' is mentioned on line 207, but not defined == Unused Reference: 'FIPS-186-2' is defined on line 242, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYS' == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 ** Downref: Normative reference to an Informational RFC: RFC 2807 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-ns' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-schema' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S. Blake-Wilson and Y.Wang 2 INTERNET-DRAFT Certicom Corp. 3 Expires: 19 September 2001 20 March 2001 5 ECDSA with XML-Signature Syntax 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts may be found at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories may be found at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document specifies how to use ECDSA (Elliptic Curve Digital 30 Signature Algorithm) with the XML-digital signature syntax. 31 The mechanism specified provides integrity, message authentication, 32 and/or signer authentication services for data of any type, whether 33 located within the XML that includes the signature or included by 34 reference. 36 Table of Contents 38 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 39 2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 3. Specifying ECDSA within XMLDSIG . . . . . . . . . . . . . . 2 41 3.1. Identifier. . . . . . . . . . . . . . . . . . . . . . . . . 2 42 3.2. Core Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3 43 3.3. ECDSA Signatures. . . . . . . . . . . . . . . . . . . . . . 4 44 3.4. ECDSA Key Values. . . . . . . . . . . . . . . . . . . . . . 4 45 4. Security Considerations . . . . . . . . . . . . . . . . . . 4 46 5. Intellectual Property Rights . . . . . . . . . . . . . . . . 5 47 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 7. Authors' address . . . . . . . . . . . . . . . . . . . . . . 6 49 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 50 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7 52 1. Introduction 54 This document specifies how to use ECDSA (Elliptic Curve Digital 55 Signature Algorithm) with the XML signature syntax. 56 The XML Digital Signature syntax, or XMLDSIG is specified in 57 [RFC2807, XMLDSIG]. Currently there are only two digital signature 58 methods defined for use within XMLDSIG: RSA signatures and DSA (DSS) 59 signatures. This document introduces ECDSA signatures as a third 60 method. 62 This specification uses both XML Schemas [XML-schema] and DTDs [XML]. 64 2. ECDSA 66 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 67 curve analogue of the DSA (also called DSS) signature method 68 [FIPS186-2]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is 69 defined in the ANSI X9.62 standard [ECDSA]; other compatible 70 specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363], 71 and SEC1 [SEC1]. [PKIX2] describes the means to carry ECDSA keys in 72 X.509 certificates. Recommended elliptic curve domain parameters for 73 use with ECDSA are given in [FIPS186-2], [SEC2], and [ECDSA]. 75 Like DSA, ECDSA incorporates the use of a hash function; currently, 76 the only hash function defined for use with ECDSA is the SHA-1 message 77 digest algorithm [FIPS-180-1]. 79 ECDSA signatures are smaller than RSA signatures of similar 80 cryptographic strength. ECDSA public keys (and certificates) are smaller 81 than similar strength DSA keys, resulting in improved communications 82 efficiency. Furthermore, on many platforms ECDSA operations can be 83 computed faster than similar strength RSA or DSA operations (see [KEYS] 84 for a security analysis of key sizes across public key algorithms). 85 These advantages of signature size, bandwidth, and computational 86 efficiency may make ECDSA an attractive choice for XMLDSIG 87 implementations. 89 3. Specifying ECDSA within XMLDSIG 91 This section specifies the details of how to use ECDSA with the 92 XML-signature syntax. It relies heavily on the syntax and namespace 93 defined in [XMLDSIG]. 95 3.1 Identifier 97 The XML namespace [XML-ns] URI that MUST be used by implementations 98 of this (dated) specification is: 99 xmlns="http://www.certicom.com/2000/11/xmlecdsig#" 100 The identifier for the ECDSA signature algorithm is: 101 http://www.certicom.com/2000/11/xmlecdsig#ecdsa-sha1 103 3.2 Core Syntax 105 The syntax is defined via DTDs and [XML-Schema] with the following XML 106 preamble, declaration, internal entity, and simpleType: 107 Schema Definition: 109 110 116 119 120 121 ]> 123 130 134 135 136 137 139 140 141 142 143 144 146 DTD: 148 152 156 3.3 ECDSA Signatures 158 The input to the ECDSA algorithm is the encoding of the SignedInfo 159 element as specified in Section 3 of [XMLDSIG]. The output of the 160 ECDSA algorithm consists of a pair of integers usually referred by 161 the pair (r, s). The signature value consists of the base64 encoding 162 of the concatenation of two octet-streams that respectively result 163 from the octet-encoding of the values r and s. r and s are each 164 converted into octet strings of length [log_2 n/8], where n is the order 165 of the elliptic curve base point, using the conversion routine specified 166 in Section 4.3.1 of ANSI X9.62 [ECDSA]. 168 3.4 ECDSA Key Values 170 The syntax used for ECDSA key values closely follows the ASN.1 syntax 171 defined in ANSI X9.62 [ECDSA]. 173 ECDSA key values consist of two elements: ECDSAPublickey and 174 ECCParameters. ECDSAPublicKey contains the ECDSA public key which 175 is a point on the elliptic curve and is encoded as a base64 value of 176 its octet-stream representation converted as specified in 177 Section 4.3.1 of ANSI X9.62 [ECDSA]. The element ECCParameters 178 specifies the associated elliptic curve domain parameters which 179 are represented by the nicknames given to them in [SEC2]. 181 Schema: 183 184 185 186 188 190 191 192 194 DTD: 196 197 198 200 4. Security Considerations 202 Implementers should ensure that appropriate security measures are in 203 place when they deploy ECDSA within XMLDSIG. In particular, the security 204 of ECDSA requires the careful selection of both key sizes and elliptic 205 curve domain parameters. Selection guidelines for these parameters and 206 some specific recommended curves that are considered safe are provided 207 in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion, 208 see [XMLDSIG]. 210 5. Intellectual Property Rights 212 The IETF has been notified of intellectual property rights claimed in 213 regard to the specification contained in this document. 214 For more information, consult the online list of claimed rights 215 (http://www.ietf.org/ipr.html). 217 The IETF takes no position regarding the validity or scope of any 218 intellectual property or other rights that might be claimed to 219 pertain to the implementation or use of the technology described in 220 this document or the extent to which any license under such rights 221 might or might not be available; neither does it represent that it 222 has made any effort to identify any such rights. Information on the 223 IETF's procedures with respect to rights in standards-track and 224 standards-related documentation can be found in BCP-11. Copies of 225 claims of rights made available for publication and any assurances of 226 licenses to be made available, or the result of an attempt made to 227 obtain a general license or permission for the use of such 228 proprietary rights by implementers or users of this specification can 229 be obtained from the IETF Secretariat. 231 6. References 233 [ECDSA] American National Standards Institute. ANSI X9.62-1998, 234 "Public Key Cryptography for the Financial Services 235 Industry: The Elliptic Curve Digital Signature 236 Algorithm". January, 1999. 238 [FIPS-180-1] Federal Information Processing Standards Publication 239 (FIPS PUB) 180-1, "Secure Hash Standard", April 17, 240 1995. 242 [FIPS-186-2] Federal Information Processing Standards Publication 243 (FIPS PUB) 186-2, "Digital Signature Standard", 244 January, 2000. 246 [IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) 247 Standard 1363-2000, "Standard Specifications for Public Key 248 Cryptography", 2000. 250 [KEYS] Lenstra, A.K. and Verheul, E.R., "Selecting Cryptographic 251 Key Sizes", October 1999. Presented at Public Key 252 Cryptography Conference, Melbourne, Australia, January, 253 2000. 254 http://www.cryptosavvy.com/ 256 [PKIX2] Bassham, L., Housley, R., and Polk, W., "Internet X.509 257 Public Key Infrastructure Representation of Public Keys 258 and Digital Signatures in Internet X.509 Public Key 259 Infrastructure Certificates", 260 draft-ietf-pkix-ipki-pkalgs-00.txt. July, 2000. 262 [RFC2807] RFC 2807. XML Signature Requirements. J. Reagle, April 2000. 263 http://www.w3.org/TR/xmldsig-requirements 265 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 266 Elliptic Curve Cryptography", Version 1.0, September, 267 2000. http://www.secg.org 269 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 270 Recommended Elliptic Curve Domain Parameters", 271 Version 1.0, September, 2000. http://www.secg.org 273 [XML] Extensible Markup Language (XML) 1.0 Recommendation. 274 T. Bray, J. Paoli, C. M. Sperberg-McQueen. February, 1998. 275 http://www.w3.org/TR/1998/REC-xml-19980210 277 [XMLDSIG] XML-Signature Syntax and Processing. 278 D. Eastlake, J. Reagle, D. Solo. July, 2000. 279 Work in progess. 280 http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/ 282 [XML-ns] Namespaces in XML Recommendation. 283 T. Bray, D. Hollander, A. Layman. Janaury 1999. 284 http://www.w3.org/TR/1999/REC-xml-names-19990114 286 [XML-schema] XML Schema Part 1: Structures Working Draft. D. Beech, M. 287 Maloney, N. Mendelshohn. April 2000. 288 http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/ 289 XML Schema Part 2: Datatypes Working Draft. P. Biron, A. 290 Malhotra. April 2000. 291 http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/ 293 7. Authors' Address 295 Simon Blake-Wilson 296 Yongge Wang 297 Certicom Corp. 298 5520 Explorer Dr. 299 Mississauga, ON, L4W 5L1 301 e-mail: {sblakewilson, ywang}@certicom.com 303 8. Acknowledgements 305 The authors would like to acknowledge the many helpful comments of 306 Donald Eastlake, Tom Gindin, Cris Hawk, Joseph M. Reagle Jr., and 307 Francois Rousseau. 309 9. Full Copyright Statement 311 Copyright (C) The Internet Society (1999). All Rights Reserved. 313 This document and translations of it may be copied and furnished to 314 others, and derivative works that comment on or otherwise explain 315 it or assist in its implementation may be prepared, copied, 316 published and distributed, in whole or in part, without restriction 317 of any kind, provided that the above copyright notice and this 318 paragraph are included on all such copies and derivative works. 319 However, this document itself may not be modified in any way, such 320 as by removing the copyright notice or references to the Internet 321 Society or other Internet organizations, except as needed for the 322 purpose of developing Internet standards in which case the procedures 323 for copyrights defined in the Internet Standards process must be 324 followed, or as required to translate it into languages other than 325 English. 327 The limited permissions granted above are perpetual and will not be 328 revoked by the Internet Society or its successors or assigns. 330 This document and the information contained herein is provided on an 331 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 332 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 333 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 334 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 335 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.