idnits 2.17.00 (12 Aug 2021) /tmp/idnits3091/draft-blake-wilson-xmldsig-ecdsa-03.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? == There is 1 instance of lines with non-ascii characters in the document. == 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 60 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. ** The abstract seems to contain references ([XMLDSIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 111: '...The XML namespace [XML-ns] URI that MUST be used by implementations of...' RFC 2119 keyword, line 141: '...definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]:...' RFC 2119 keyword, line 200: '...[X9.62], [FIPS-186-2] or [SEC2], the OIDs of these curves SHOULD be used...' 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 (30 June 2002) is 7264 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 84, but not defined == Missing Reference: 'NIST-ECC' is mentioned on line 441, but not defined -- 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' ** Downref: Normative reference to an Informational RFC: RFC 3061 -- 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 (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S. Blake-Wilson, BCI 2 G. Karlinger, CIO Austria 3 INTERNET-DRAFT Y. Wang, UNCC 4 Expires: 31 December 2002 30 June 2002 6 ECDSA with XML-Signature Syntax 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts may be found at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories may be found at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document specifies how to use ECDSA (Elliptic Curve Digital 31 Signature Algorithm) with XML Signatures [XMLDSIG]. The mechanism 32 specified provides integrity, message authentication, and/or signer 33 authentication services for data of any type, whether located 34 within the XML that includes the signature or included by reference. 36 Table of Contents 38 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 39 2 ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 40 3 Specifying ECDSA within XMLDSIG . . . . . . . . . . . . . . . . 3 41 3.1 Version, Namespaces and Identifiers . . . . . . . . . . . . 3 42 3.1.1 XML Schema Preamble . . . . . . . . . . . . . . . . 3 43 3.1.2 DTD Replacement . . . . . . . . . . . . . . . . . . 3 44 3.2 XML Schema Preamble and DTD Replacement . . . . . . . . . . 4 45 3.2.1 XML Schema Preamble . . . . . . . . . . . . . . . . . 4 46 3.2.2 DTD Replacement . . . . . . . . . . . . . . . . . . . 4 47 3.3 ECDSA Signatures . . . . . . . . . . . . . . . . . . . . . 4 48 3.4 ECDSA Key Values . . . . . . . . . . . . . . . . . . . . . 4 49 3.4.1 Key Value Root Element . . . . . . . . . . . . . . . 5 50 3.4.2 EC Domain Parameters . . . . . . . . . . . . . . . . 5 51 3.4.2.1 Field Parameters . . . . . . . . . . . . . 6 52 3.4.2.2 Curve Parameters . . . . . . . . . . . . . 8 53 3.4.2.3 Base Point Parameters . . . . . . . . . . . 9 54 3.4.3 EC Points . . . . . . . . . . . . . . . . . . . . . 10 55 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 56 5 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 11 57 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 7 Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . 13 59 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 60 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 62 Appendix A: Aggregate XML Schema . . . . . . . . . . . . . . . . . 14 63 Appendix B: Aggregate DTD . . . . . . . . . . . . . . . . . . . . . 17 65 1. Introduction 67 This document specifies how to use the Elliptic Curve Digital Signature 68 Algorithm (ECDSA) with XML signatures as specified in [XMLDSIG]. Therein 69 only two digital signature methods are defined: RSA signatures and DSA 70 (DSS) signatures. This document introduces ECDSA signatures as an 71 additional method. 73 This document uses both XML Schemas [XML-schema] (normative) and DTDs 74 [XML] (informational) for specifying the corresponding XML structures. 76 2. ECDSA 78 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 79 curve analogue of the DSA (DSS) signature method [FIPS186-2]. It is 80 defined in the ANSI X9.62 standard [X9.62]. Other compatible 81 specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363], 82 and SEC1 [SEC1]. [RFC3279] describes the means to carry ECDSA keys in 83 X.509 certificates. Recommended elliptic curve domain parameters for 84 use with ECDSA are given in [FIPS186-2], [SEC2], and [X9.62]. 86 Like DSA, ECDSA incorporates the use of a hash function. Currently,the 87 only hash function defined for use with ECDSA is the SHA-1 message 88 digest algorithm [FIPS-180-1]. 90 ECDSA signatures are smaller than RSA signatures of similar 91 cryptographic strength. ECDSA public keys (and certificates) are smaller 92 than similar strength DSA keys, resulting in improved communications 93 efficiency. Furthermore, on many platforms ECDSA operations can be 94 computed faster than similar strength RSA or DSA operations (see [KEYS] 95 for a security analysis of key sizes across public key algorithms). 96 These advantages of signature size, bandwidth, and computational 97 efficiency may make ECDSA an attractive choice for XMLDSIG 98 implementations. 100 3. Specifying ECDSA within XMLDSIG 102 This section specifies the details of how to use ECDSA with XML 103 Signature Syntax and Processing [XMLDSIG]. It relies heavily on the 104 syntax and namespace defined therein. 106 3.1 Version, Namespaces and Identifiers 108 No provision is made for an explicit version number in this syntax. If 109 a future version is needed, it will use a different namespace. 111 The XML namespace [XML-ns] URI that MUST be used by implementations of 112 this (dated) specification is: 113 http://www.buergerkarte.at/namespaces/ecdsa/200206030# 115 Elements in the namespace of the [XMLDSIG] specification are marked as 116 such by using the namespace prefix "dsig" in the remaining sections of 117 this document. 119 The identifier for the ECDSA signature algorithm is: 120 http://www.buergerkarte.at/namespaces/ecdsa/200206030#ecdsa-sha1 122 3.2 XML Schema Preamble and DTD Replacement 124 3.2.1 XML Schema Preamble 126 The subsequent preamble is to be used with the XML Schema definitions 127 given in the remaining sections of this document. 129 130 138 3.2.2 DTD Replacement 140 In order to include ECDSA in XML-signature syntax, the following 141 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 143 145 3.3 ECDSA Signatures 147 The input to the ECDSA algorithm is the canonicalized represenation of 148 the dsig:SignedInfo element as specified in Section 3 of [XMLDSIG]. 150 The output of the ECDSA algorithm consists of a pair of integers usually 151 referred by the pair (r, s). The signature value (text value of element 152 dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the 153 base64 encoding of the concatenation of two octet-streams that 154 respectively result from the octet-encoding of the values r and s. This 155 concatenation is described in section E3.1 of [IEEE1363]. 157 3.4 ECDSA Key Values 159 The syntax used for ECDSA key values closely follows the ASN.1 syntax 160 defined in ANSI X9.62 [X9.62]. 162 3.4.1 Key Value Root Element 164 The element ECDSAKeyValue is used for encoding ECDSA public keys. For 165 use with XMLDSIG simply use this element inside dsig:KeyValue, such as 166 the predefined elements dsig:RSAKeyValue or dsig:DSAKeyValue. 168 The element consists of an optional subelement DomainParameters and the 169 mandatory subelement PublicKey. If Domainparameters is missing in an 170 instance, this means that the application knows about them from other 171 means (implicitly). 173 Schema Definition: 175 177 178 179 181 182 183 185 DTD Definition: 187 188 189 190 191 192 194 3.4.2 EC Domain Parameters 196 Domain parameters can be encoded either explicitly using element 197 ExplicitParams, or by reference using element NamedCurve. The latter 198 simply consists of an attribute named URN, which bears a uniform 199 ressource name as its value. For the named curves of standards like 200 [X9.62], [FIPS-186-2] or [SEC2], the OIDs of these curves SHOULD be used 201 in this attribute, e. g. URN="urn:oid:1.2.840.10045.3.1.1". The 202 mechanism for encoding OIDs in URNs is shown in [RFC3061]. 204 Schema Definition: 206 207 208 210 211 212 213 214 215 216 218 DTD Definition: 220 221 222 224 The element ExplicitParams is used for explicit encoding of domain 225 parameters. It contains three subelements: FieldParams describes the 226 underlying field, CurveParams describes the elliptic curve, and 227 BasePointParams describes the base point of the elliptic curve. 229 Schema Definition: 231 232 233 234 235 237 238 240 DTD Definition: 242 244 3.4.2.1 Field Parameters 246 The element FieldParams is used for encoding field parameters. The 247 corresponding XML Schema type FieldParamsType is declared abstract and 248 will be extended by specialized types for prime field an characteristic 249 two field parameters. 251 The XML Schema type PrimeFieldParamsType is derived from FieldParamsType 252 and is used for for encoding prime field parameters. The type contains 253 as its single subelement P, the order of the prime field. 255 The XML Schema type CharTwoFieldParamsType is derived from 256 FieldParamsType as well and is used for encoding parameters of a 257 characteristic two field. It is again an abstract type and will be 258 extended by specialized types for trinomial base fields and pentanomial 259 base fields. F2m Gaussian Normal Base fields are not supported by this 260 specification to relieve interoperability. Common to both specialized 261 types is the element M, the extension degree of the field. 263 The XML Schema type TnBFieldParamsType is derived from 264 CharTwoFieldParamsType and is used for encoding trinomial base fields. 265 It adds the single element K, which represents the integer k, where 266 x^m + x^k + 1 is the reduction polynomial. 268 The XML Schema type PnBFieldParamsType is derived from 269 CharTwoFieldParamsType as well and is used for encoding pentanomial base 270 fields. It adds the three elements K1, K2 and K3, which represent the 271 integers k1, k2 and k3 respectively, where x^m + x^k3 + x^k2 + x^k1 + 1 272 is the reduction polynomial. 274 Schema Definition: 276 278 279 280 281 282 283 284 285 286 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 307 308 309 310 311 312 313 314 315 316 317 319 DTD Definition: 321 322 323 324 325 326 327 329 3.4.2.2 Curve Parameters 331 The element CurveParams is used for encoding parameters of the elliptic 332 curve. The corresponding XML Schema type CurveParamsType bears the 333 elements A and B representing the coefficients a and b of the elliptic 334 curve, while the optional element Seed contains the value used to derive 335 the coefficients of a randomly generated elliptic curve, according to 336 the algorithm specified in annex A3.3 of [X9.62]. 338 Schema Definition: 340 341 342 343 344 345 346 348 DTD Definition: 350 351 352 353 354 355 357 3.4.2.3 Base Point Parameters 359 The element BasePointParams is used for encoding parameters regarding 360 the base point of the elliptic curve. BasePoint represents the base 361 point itself, Order provides the order of the base point, and Cofactor 362 optionally provides the cofactor of the base point. 364 Schema Definition: 366 367 368 369 370 372 373 375 DTD Definition: 377 378 379 380 382 3.4.3 EC Points 384 The XML Schema type ECPointType is used for encoding a point on the 385 elliptic curve. It consists of the subelements X and Y, providing the 386 x and y coordinates of the point. Point compression representation is 387 not supported by this specification for the sake of simple design. 389 The point at infinity is encoded by omitting both elements X and Y. 391 The subelements X and Y are of type FieldElemType. This is an abstract 392 type for encoding elements of the elliptic curveÆs underlying field and 393 is extended by specialized types for prime field elements and 394 characteristic two field elements. 396 The XML Schema type PrimeFieldElemType is used for encoding prime field 397 elements. It contains a single attribute named Value, whose value 398 represents the field element as an integer. 400 The XML Schema type CharTwoFieldElemType is used for encoding 401 characteristic two field elements. It Contains a single attribute named 402 Value, whose value represents the field element as an octet string. The 403 octet string must be composed as shown in paragraph 2 of section 4.3.3 404 of [X9.62]. 406 Schema Definition: 408 409 410 411 412 413 415 417 418 419 420 422 423 424 425 426 427 428 430 431 432 434 4. Security Considerations 436 Implementers should ensure that appropriate security measures are in 437 place when they deploy ECDSA within XMLDSIG. In particular, the security 438 of ECDSA requires the careful selection of both key sizes and elliptic 439 curve domain parameters. Selection guidelines for these parameters and 440 some specific recommended curves that are considered safe are provided 441 in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion, 442 see [XMLDSIG]. 444 5. Intellectual Property Rights 446 The IETF has been notified of intellectual property rights claimed in 447 regard to the specification contained in this document. 448 For more information, consult the online list of claimed rights 449 (http://www.ietf.org/ipr.html). 451 The IETF takes no position regarding the validity or scope of any 452 intellectual property or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; neither does it represent that it 456 has made any effort to identify any such rights. Information on the 457 IETF's procedures with respect to rights in standards-track and 458 standards-related documentation can be found in BCP-11. Copies of 459 claims of rights made available for publication and any assurances of 460 licenses to be made available, or the result of an attempt made to 461 obtain a general license or permission for the use of such 462 proprietary rights by implementers or users of this specification can 463 be obtained from the IETF Secretariat. 465 6. References 467 [FIPS-180-1] Federal Information Processing Standards Publication 468 (FIPS PUB) 180-1, Secure Hash Standard, April 1995. 470 [FIPS-186-2] Federal Information Processing Standards Publication 471 (FIPS PUB) 186-2, Digital Signature Standard. January 472 2000. 474 [IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) 475 Standard 1363-2000, Standard Specifications for Public Key 476 Cryptography. January 2000. 478 [KEYS] Lenstra, A.K. and Verheul, E.R., Selecting Cryptographic Key 479 Sizes. October 1999. Presented at Public Key Cryptography 480 Conference, Melbourne, Australia, January 2000. 481 http://www.cryptosavvy.com/ 483 [RFC3061] Mealling, M., RFC 3061, A URN Namespace of Object 484 Identifiers. IETF Informational RFC, February 2001. 485 http://www.ietf.org/rfc/rfc3061.txt 487 [RFC3279] Bassham, L., Housley, R., and Polk, W., RFC 3279, Algorithms 488 and Identifiers for the Internet X.509 Public Key 489 Infrastructure Certificate and Certificate Revocation List 490 (CRL) Profile. IETF Proposed Standard, April 2002. 491 http://www.ietf.org/rfc/rfc3279.txt 493 [SEC1] Standards for Efficient Cryptography Group, SEC 1: Elliptic 494 Curve Cryptography, Version 1.0, September 2000. 495 http://www.secg.org 497 [SEC2] Standards for Efficient Cryptography Group, SEC 2: Recommended 498 Elliptic Curve Domain Parameters, Version 1.0, September 2000. 499 http://www.secg.org 501 [X9.62] American National Standards Institute. ANSI X9.62-1998, 502 Public Key Cryptography for the Financial Services Industry: 503 The Elliptic Curve Digital Signature Algorithm. January 1999. 505 [XML] Bray, T., Maler, E., Paoli, J. , and Sperberg-McQueen, C. M., 506 Extensible Markup Language (XML) 1.0 (Second Edition), W3C 507 Recommendation, October 2000. 508 http://www.w3.org/TR/2000/REC-xml-20001006 510 [XMLDSIG] Eastlake, D., Reagle, J., and Solo, D., XML-Signature 511 Syntax and Processing. W3C Recommendation, February 2002. 512 http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 514 [XML-ns] Bray, T., Hollander, D., and Layman, A., Namespaces in XML, 515 W3C Recommendation, January 1999. 516 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 518 [XML-schema] Beech, D., Maloney, M., Mendelsohn, N., and Thompson, 519 H., XML Schema Part 1: Structures, W3C Recommendation, 520 May 2001. 521 http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ 522 Biron, P., and Malhotra, A., ML Schema Part 2: 523 Datatypes, W3C Recommendation, May 2001. 524 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 526 7. Authors' Addresses 528 Simon Blake-Wilson 529 BCI 530 96 Spadina Ave, Unit 606 531 Toronto, ON, M5V 2J6, Canada 532 e-mail: sblakewilson@bcisse.com 534 Gregor Karlinger 535 Chief Information Office Austria 536 Parkring 10/I/5 537 1010 Wien, Austria 538 e-mail: gregor.karlinger@cio.gv.at 540 Yongge Wang 541 University of North Carolina at Charlotte 542 9201 University City Blvd 543 Charlotte, NC 28223, USA 544 e-mail: ywang@uncc.edu 546 8. Acknowledgements 548 The authors would like to acknowledge the many helpful comments of 549 Wolfgang Bauer, Donald Eastlake, Tom Gindin, Chris Hawk, Joseph M. 550 Reagle Jr., and Francois Rousseau. 552 9. Full Copyright Statement 554 Copyright (C) The Internet Society (1999). All Rights Reserved. 556 This document and translations of it may be copied and furnished to 557 others, and derivative works that comment on or otherwise explain 558 it or assist in its implementation may be prepared, copied, 559 published and distributed, in whole or in part, without restriction 560 of any kind, provided that the above copyright notice and this 561 paragraph are included on all such copies and derivative works. 562 However, this document itself may not be modified in any way, such 563 as by removing the copyright notice or references to the Internet 564 Society or other Internet organizations, except as needed for the 565 purpose of developing Internet standards in which case the procedures 566 for copyrights defined in the Internet Standards process must be 567 followed, or as required to translate it into languages other than 568 English. 570 The limited permissions granted above are perpetual and will not be 571 revoked by the Internet Society or its successors or assigns. 573 This document and the information contained herein is provided on an 574 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 575 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 576 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 577 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 578 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 580 Appendix A: Aggregate XML Schema 582 583 592 594 595 596 597 599 600 601 602 604 605 606 608 609 610 611 612 613 614 615 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 661 662 663 664 665 666 667 668 669 670 671 672 673 674 676 677 679 681 682 683 684 685 686 687 689 690 691 692 693 695 696 697 698 699 700 701 703 704 705 706 708 Appendix A: Aggregate DTD 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736