idnits 2.17.00 (12 Aug 2021) /tmp/idnits2177/draft-blake-wilson-xmldsig-ecdsa-01.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 65 lines 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 5 instances of too long lines in the document, the longest one being 7 characters 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 95: '...The XML namespace [XML-ns] URI that MUST be used by implementations...' RFC 2119 keyword, line 128: '...finition of the KeyValue schema SHOULD...' RFC 2119 keyword, line 146: '...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 (13 November 2000) is 7858 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 69, but not defined == Missing Reference: 'XML-Schema' is mentioned on line 103, but not defined == Missing Reference: 'NIST-ECC' is mentioned on line 202, but not defined == Unused Reference: 'FIPS-186-2' is defined on line 237, 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 (~~), 8 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: 12 May 2001 13 November 2000 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. . . . . . . . . . . . . . . . . . . . . . 3 44 3.4. ECDSA Key Values. . . . . . . . . . . . . . . . . . . . . . 4 45 4. Security Considerations . . . . . . . . . . . . . . . . . . 4 46 5. Intellectual Property Rights . . . . . . . . . . . . . . . . 4 47 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 7. Authors' address . . . . . . . . . . . . . . . . . . . . . . 6 49 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7 51 1. Introduction 53 This document specifies how to use ECDSA (Elliptic Curve Digital 54 Signature Algorithm) with the XML signature syntax. 55 The XML Digital Signature syntax, or XMLDSIG is specified in 56 [RFC2807, XMLDSIG]. Currently there are only two digital signature 57 methods defined for use within XMLDSIG: RSA signatures and DSA (DSS) 58 signatures. This document introduces ECDSA signatures as a third 59 method. 61 This specification uses both XML Schemas [XML-schema] and DTDs [XML]. 63 2. ECDSA 65 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 66 curve analogue of the DSA (also called DSS) signature method 67 [FIPS186-2]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is 68 defined in the ANSI X9.62 standard [ECDSA]; other compatible 69 specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363], 70 and SEC1 [SEC1]. [PKIX2] describes the means to carry ECDSA keys in 71 X.509 certificates. Recommended elliptic curve domain parameters for 72 use with ECDSA are given in [SEC2]. 74 Like DSA, ECDSA incorporates the use of a hash function; currently, 75 the only hash function defined for use with ECDSA is the SHA-1 message 76 digest algorithm [FIPS-180-1]. 78 ECDSA signatures are smaller than RSA signatures of similar 79 cryptographic strength. ECDSA public keys (and certificates) are smaller 80 than similar strength DSA keys, resulting in improved communications 81 efficiency. Furthermore, on many platforms ECDSA operations can be 82 computed faster than similar strength RSA or DSA operations (see [KEYS] 83 for a security analysis of key sizes across public key algorithms). 84 These advantages of signature size, bandwidth, and computational 85 efficiency may make ECDSA an attractive choice for XMLDSIG implementations. 87 3. Specifying ECDSA within XMLDSIG 89 This section specifies the details of how to use ECDSA with the 90 XML-signature syntax. It relies heavily on the syntax and namespace 91 defined in [XMLDSIG]. 93 3.1 Identifier 95 The XML namespace [XML-ns] URI that MUST be used by implementations 96 of this (dated) specification is: 97 xmlns="http://www.certicom.com/2000/11/xmlecdsig#" 98 The identifier for the ECDSA signature algorithm is: 99 http://www.certicom.com/2000/11/xmlecdsig#ecdsa-sha1 101 3.2 Core Syntax 103 The syntax is defined via DTDs and [XML-Schema] with the following XML 104 preamble, declaration, internal entity, and simpleType: 105 Schema Definition: 107 108 114 116 117 118 ]> 120 127 131 132 133 134 136 137 138 139 140 141 143 DTD: 145 149 153 3.3 ECDSA Signatures 155 The output of the ECDSA algorithm consists of a pair of integers 156 usually referred by the pair (r, s). The signature value consists 157 of the base64 encoding of the concatenation of two octet-streams that 158 respectively result from the octet-encoding of the values r and s. 159 r and s are converted into octet strings of length [log_2 n/8], where 160 n is the order of the elliptic curve base point, using the 161 conversion routine specified in Section 4.3.1 of ANSI X9.62 [ECDSA]. 163 3.4 ECDSA Key Values 165 The syntax used for ECDSA key values closely follows the ASN.1 syntax 166 defined in ANSI X9.62 [ECDSA]. 168 ECDSA key values consist of two elements: ECDSAPublickey and 169 ECCParameters. ECDSAPublicKey contains the ECDSA public key which 170 is a point on the elliptic curve and is encoded as a base64 value of 171 its octet-stream representation converted as specified in 172 Section 4.3.1 of ANSI X9.62 [ECDSA]. The element ECCParameters 173 specifies the associated elliptic curve domain parameters which 174 are represented by the nicknames given to them in [SEC2]. 176 Schema: 178 179 180 181 183 185 186 187 189 DTD: 191 192 193 195 4. Security Considerations 197 Implementers should ensure that appropriate security measures are in 198 place when they deploy ECDSA within XMLDSIG. In particular, the security 199 of ECDSA requires the careful selection of both key sizes and elliptic 200 curve domain parameters. Selection guidelines for these parameters and 201 some specific recommended curves that are considered safe are provided 202 in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion, 203 see [XMLDSIG]. 205 5. Intellectual Property Rights 207 The IETF has been notified of intellectual property rights claimed in 208 regard to the specification contained in this document. 209 For more information, consult the online list of claimed rights 210 (http://www.ietf.org/ipr.html). 212 The IETF takes no position regarding the validity or scope of any 213 intellectual property or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; neither does it represent that it 217 has made any effort to identify any such rights. Information on the 218 IETF's procedures with respect to rights in standards-track and 219 standards-related documentation can be found in BCP-11. Copies of 220 claims of rights made available for publication and any assurances of 221 licenses to be made available, or the result of an attempt made to 222 obtain a general license or permission for the use of such 223 proprietary rights by implementers or users of this specification can 224 be obtained from the IETF Secretariat. 226 6. References 228 [ECDSA] American National Standards Institute. ANSI X9.62-1998, 229 "Public Key Cryptography for the Financial Services 230 Industry: The Elliptic Curve Digital Signature 231 Algorithm". January, 1999. 233 [FIPS-180-1] Federal Information Processing Standards Publication 234 (FIPS PUB) 180-1, "Secure Hash Standard", April 17, 235 1995. 237 [FIPS-186-2] Federal Information Processing Standards Publication 238 (FIPS PUB) 186-2, "Digital Signature Standard", 239 January, 2000. 241 [IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) 242 Standard 1363-2000, "Standard Specifications for Public Key 243 Cryptography", 2000. 245 [KEYS] Lenstra, A.K. and Verheul, E.R., "Selecting Cryptographic 246 Key Sizes", October 1999. Presented at Public Key 247 Cryptography Conference, Melbourne, Australia, January, 248 2000. 249 http://www.cryptosavvy.com/ 251 [PKIX2] Bassham, L., Housley, R., and Polk, W., "Internet X.509 252 Public Key Infrastructure Representation of Public Keys 253 and Digital Signatures in Internet X.509 Public Key 254 Infrastructure Certificates", 255 draft-ietf-pkix-ipki-pkalgs-00.txt. July, 2000. 257 [RFC2807] RFC 2807. XML Signature Requirements. J. Reagle, April 2000. 258 http://www.w3.org/TR/xmldsig-requirements 260 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 261 Elliptic Curve Cryptography", Version 0.5, September, 262 1999. 263 http://www.secg.org 265 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 266 Recommended Elliptic Curve Domain Parameters", 267 Version 0.6, October, 1999. 269 [XML] Extensible Markup Language (XML) 1.0 Recommendation. 270 T. Bray, J. Paoli, C. M. Sperberg-McQueen. February, 1998. 271 http://www.w3.org/TR/1998/REC-xml-19980210 273 [XMLDSIG] XML-Signature Syntax and Processing. 274 D. Eastlake, J. Reagle, D. Solo. July, 2000. 275 Work in progess. 276 http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/ 278 [XML-ns] Namespaces in XML Recommendation. 279 T. Bray, D. Hollander, A. Layman. Janaury 1999. 280 http://www.w3.org/TR/1999/REC-xml-names-19990114 282 [XML-schema] XML Schema Part 1: Structures Working Draft. D. Beech, M. 283 Maloney, N. Mendelshohn. April 2000. 284 http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/ 285 XML Schema Part 2: Datatypes Working Draft. P. Biron, A. 286 Malhotra. April 2000. 287 http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/ 289 7. Authors' Address 291 Simon Blake-Wilson 292 Yongge Wang 293 Certicom Corp. 294 5520 Explorer Dr. 295 Mississauga, ON, L4W 5L1 297 e-mail: {sblakewilson, ywang}@certicom.com 299 8. Full Copyright Statement 301 Copyright (C) The Internet Society (1999). All Rights Reserved. 303 This document and translations of it may be copied and furnished to 304 others, and derivative works that comment on or otherwise explain 305 it or assist in its implementation may be prepared, copied, 306 published and distributed, in whole or in part, without restriction 307 of any kind, provided that the above copyright notice and this 308 paragraph are included on all such copies and derivative works. 309 However, this document itself may not be modified in any way, such 310 as by removing the copyright notice or references to the Internet 311 Society or other Internet organizations, except as needed for the 312 purpose of developing Internet standards in which case the procedures 313 for copyrights defined in the Internet Standards process must be 314 followed, or as required to translate it into languages other than 315 English. 317 The limited permissions granted above are perpetual and will not be 318 revoked by the Internet Society or its successors or assigns. 320 This document and the information contained herein is provided on an 321 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 322 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 323 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 324 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 325 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.