idnits 2.17.00 (12 Aug 2021) /tmp/idnits1760/draft-blake-wilson-xmldsig-ecdsa-00.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 5) being 59 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 130: '...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 186, but not defined == Unused Reference: 'FIPS-186-2' is defined on line 221, 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 DTD: 129 133 137 3.3 ECDSA Signatures 139 The output of the ECDSA algorithm consists of a pair of integers 140 usually referred by the pair (r, s). The signature value consists 141 of the base64 encoding of the concatenation of two octet-streams that 142 respectively result from the octet-encoding of the values r and s. 143 r and s are converted into octet strings of length [log_2 n/8], where 144 n is the order of the elliptic curve base point, using the 145 conversion routine specified in Section 4.3.1 of ANSI X9.62 [ECDSA]. 147 3.4 ECDSA Key Values 149 The syntax used for ECDSA key values closely follows the ASN.1 syntax 150 defined in ANSI X9.62 [ECDSA]. 152 ECDSA key values consist of two elements: ECDSAPublickey and 153 ECCParameters. ECDSAPublicKey contains the ECDSA public key which 154 is a point on the elliptic curve and is encoded as a base64 value of 155 its octet-stream representation converted as specified in 156 Section 4.3.1 of ANSI X9.62 [ECDSA]. The element ECCParameters 157 specifies the associated elliptic curve domain parameters which 158 are represented by the nicknames given to them in [SEC2]. 160 Schema: 162 163 164 165 167 169 170 171 173 DTD: 175 176 177 179 4. Security Considerations 181 Implementers should ensure that appropriate security measures are in 182 place when they deploy ECDSA within XMLDSIG. In particular, the security 183 of ECDSA requires the careful selection of both key sizes and elliptic 184 curve domain parameters. Selection guidelines for these parameters and 185 some specific recommended curves that are considered safe are provided 186 in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion, 187 see [XMLDSIG]. 189 5. Intellectual Property Rights 191 The IETF has been notified of intellectual property rights claimed in 192 regard to the specification contained in this document. 193 For more information, consult the online list of claimed rights 194 (http://www.ietf.org/ipr.html). 196 The IETF takes no position regarding the validity or scope of any 197 intellectual property or other rights that might be claimed to 198 pertain to the implementation or use of the technology described in 199 this document or the extent to which any license under such rights 200 might or might not be available; neither does it represent that it 201 has made any effort to identify any such rights. Information on the 202 IETF's procedures with respect to rights in standards-track and 203 standards-related documentation can be found in BCP-11. Copies of 204 claims of rights made available for publication and any assurances of 205 licenses to be made available, or the result of an attempt made to 206 obtain a general license or permission for the use of such 207 proprietary rights by implementers or users of this specification can 208 be obtained from the IETF Secretariat. 210 6. References 212 [ECDSA] American National Standards Institute. ANSI X9.62-1998, 213 "Public Key Cryptography for the Financial Services 214 Industry: The Elliptic Curve Digital Signature 215 Algorithm". January, 1999. 217 [FIPS-180-1] Federal Information Processing Standards Publication 218 (FIPS PUB) 180-1, "Secure Hash Standard", April 17, 219 1995. 221 [FIPS-186-2] Federal Information Processing Standards Publication 222 (FIPS PUB) 186-2, "Digital Signature Standard", 223 January, 2000. 225 [IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) 226 Standard 1363-2000, "Standard Specifications for Public Key 227 Cryptography", 2000. 229 [KEYS] Lenstra, A.K. and Verheul, E.R., "Selecting Cryptographic 230 Key Sizes", October 1999. Presented at Public Key 231 Cryptography Conference, Melbourne, Australia, January, 232 2000. 233 http://www.cryptosavvy.com/ 235 [PKIX2] Bassham, L., Housley, R., and Polk, W., "Internet X.509 236 Public Key Infrastructure Representation of Public Keys 237 and Digital Signatures in Internet X.509 Public Key 238 Infrastructure Certificates", 239 draft-ietf-pkix-ipki-pkalgs-00.txt. July, 2000. 241 [RFC2807] RFC 2807. XML Signature Requirements. J. Reagle, April 2000. 242 http://www.w3.org/TR/xmldsig-requirements 244 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 245 Elliptic Curve Cryptography", Version 0.5, September, 246 1999. 247 http://www.secg.org 249 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 250 Recommended Elliptic Curve Domain Parameters", 251 Version 0.6, October, 1999. 253 [XML] Extensible Markup Language (XML) 1.0 Recommendation. 254 T. Bray, J. Paoli, C. M. Sperberg-McQueen. February, 1998. 255 http://www.w3.org/TR/1998/REC-xml-19980210 257 [XMLDSIG] XML-Signature Syntax and Processing. 258 D. Eastlake, J. Reagle, D. Solo. July, 2000. 259 Work in progess. 260 http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/ 262 [XML-ns] Namespaces in XML Recommendation. 263 T. Bray, D. Hollander, A. Layman. Janaury 1999. 264 http://www.w3.org/TR/1999/REC-xml-names-19990114 266 [XML-schema] XML Schema Part 1: Structures Working Draft. D. Beech, M. 267 Maloney, N. Mendelshohn. April 2000. 268 http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/ 269 XML Schema Part 2: Datatypes Working Draft. P. Biron, A. 270 Malhotra. April 2000. 271 http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/ 273 7. Authors' Address 275 Simon Blake-Wilson 276 Yongge Wang 277 Certicom Corp. 278 5520 Explorer Dr. 279 Mississauga, ON, L4W 5L1 281 e-mail: {sblakewilson, ywang}@certicom.com 283 8. Full Copyright Statement 285 Copyright (C) The Internet Society (1999). All Rights Reserved. 287 This document and translations of it may be copied and furnished to 288 others, and derivative works that comment on or otherwise explain 289 it or assist in its implementation may be prepared, copied, 290 published and distributed, in whole or in part, without restriction 291 of any kind, provided that the above copyright notice and this 292 paragraph are included on all such copies and derivative works. 293 However, this document itself may not be modified in any way, such 294 as by removing the copyright notice or references to the Internet 295 Society or other Internet organizations, except as needed for the 296 purpose of developing Internet standards in which case the procedures 297 for copyrights defined in the Internet Standards process must be 298 followed, or as required to translate it into languages other than 299 English. 301 The limited permissions granted above are perpetual and will not be 302 revoked by the Internet Society or its successors or assigns. 304 This document and the information contained herein is provided on an 305 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 306 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 307 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 308 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 309 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.