idnits 2.17.00 (12 Aug 2021) /tmp/idnits978/draft-blake-wilson-xmldsig-ecdsa-06.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. ** 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 113: '...The XML namespace [XML-ns] URI that MUST be used by implementations of...' RFC 2119 keyword, line 142: '...definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]:...' RFC 2119 keyword, line 201: '...[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 (November 2003) is 6761 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 85, but not defined == Missing Reference: 'NIST-ECC' is mentioned on line 477, 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. 'IEEE1363a' -- 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 (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Blake-Wilson, BCI 3 G. Karlinger, CIO Austria 4 T. Kobayashi, NTT 5 Y. Wang, UNCC 6 Expires: May 2004 November 2003 8 ECDSA with XML-Signature Syntax 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts may be found at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories may be found at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies how to use ECDSA (Elliptic Curve Digital 33 Signature Algorithm) with XML Signatures [XMLDSIG]. The mechanism 34 specified provides integrity, message authentication, and/or signer 35 authentication services for data of any type, whether located 36 within the XML that includes the signature or included by reference. 38 Table of Contents 40 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 41 2 ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 3 Specifying ECDSA within XMLDSIG . . . . . . . . . . . . . . . . 3 43 3.1 Version, Namespaces and Identifiers . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 8 54 3.4.3 EC Points . . . . . . . . . . . . . . . . . . . . . 9 56 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 57 5 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 10 58 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 7 Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . 12 60 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 61 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 63 Appendix A: Aggregate XML Schema . . . . . . . . . . . . . . . . . 13 64 Appendix B: Aggregate DTD . . . . . . . . . . . . . . . . . . . . . 16 66 1. Introduction 68 This document specifies how to use the Elliptic Curve Digital Signature 69 Algorithm (ECDSA) with XML signatures as specified in [XMLDSIG]. Therein 70 only two digital signature methods are defined: RSA signatures and DSA 71 (DSS) signatures. This document introduces ECDSA signatures as an 72 additional method. 74 This document uses both XML Schemas [XML-schema] (normative) and DTDs 75 [XML] (informational) for specifying the corresponding XML structures. 77 2. ECDSA 79 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 80 curve analogue of the DSA (DSS) signature method [FIPS186-2]. It is 81 defined in the ANSI X9.62 standard [X9.62]. Other compatible 82 specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363], 83 IEEE 1363a [IEEE1363a], and SEC1 [SEC1]. [RFC3279] describes the means 84 to carry ECDSA keys in X.509 certificates. Recommended elliptic curve 85 domain parameters for use with ECDSA are given in [FIPS186-2], [SEC2], 86 and [X9.62]. 88 Like DSA, ECDSA incorporates the use of a hash function. Currently,the 89 only hash function defined for use with ECDSA is the SHA-1 message 90 digest algorithm [FIPS-180-1]. 92 ECDSA signatures are smaller than RSA signatures of similar 93 cryptographic strength. ECDSA public keys (and certificates) are smaller 94 than similar strength DSA keys, resulting in improved communications 95 efficiency. Furthermore, on many platforms ECDSA operations can be 96 computed faster than similar strength RSA or DSA operations (see [KEYS] 97 for a security analysis of key sizes across public key algorithms). 98 These advantages of signature size, bandwidth, and computational 99 efficiency may make ECDSA an attractive choice for XMLDSIG 100 implementations. 102 3. Specifying ECDSA within XMLDSIG 104 This section specifies the details of how to use ECDSA with XML 105 Signature Syntax and Processing [XMLDSIG]. It relies heavily on the 106 syntax and namespace defined therein. 108 3.1 Version, Namespaces and Identifiers 110 No provision is made for an explicit version number in this syntax. If 111 a future version is needed, it will use a different namespace. 113 The XML namespace [XML-ns] URI that MUST be used by implementations of 114 this (dated) specification is: 115 http://www.w3.org/2001/04/xmldsig-more# 117 Elements in the namespace of the [XMLDSIG] specification are marked as 118 such by using the namespace prefix "dsig" in the remaining sections of 119 this document. 121 The identifier for the ECDSA signature algorithm is: 122 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 124 3.2 XML Schema Preamble and DTD Replacement 126 3.2.1 XML Schema Preamble 128 The subsequent preamble is to be used with the XML Schema definitions 129 given in the remaining sections of this document. 131 132 139 3.2.2 DTD Replacement 141 In order to include ECDSA in XML-signature syntax, the following 142 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 144 146 3.3 ECDSA Signatures 148 The input to the ECDSA algorithm is the canonicalized representation of 149 the dsig:SignedInfo element as specified in Section 3 of [XMLDSIG]. 151 The output of the ECDSA algorithm consists of a pair of integers usually 152 referred by the pair (r, s). The signature value (text value of element 153 dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the 154 base64 encoding of the concatenation of two octet-streams that 155 respectively result from the octet-encoding of the values r and s. This 156 concatenation is described in section E3.1 of [IEEE1363]. 158 3.4 ECDSA Key Values 160 The syntax used for ECDSA key values closely follows the ASN.1 syntax 161 defined in ANSI X9.62 [X9.62]. 163 3.4.1 Key Value Root Element 165 The element ECDSAKeyValue is used for encoding ECDSA public keys. For 166 use with XMLDSIG simply use this element inside dsig:KeyValue, such as 167 the predefined elements dsig:RSAKeyValue or dsig:DSAKeyValue. 169 The element consists of an optional subelement DomainParameters and the 170 mandatory subelement PublicKey. If Domainparameters is missing in an 171 instance, this means that the application knows about them from other 172 means (implicitly). 174 Schema Definition: 176 178 179 180 182 183 184 186 DTD Definition: 188 189 190 191 192 193 195 3.4.2 EC Domain Parameters 197 Domain parameters can be encoded either explicitly using element 198 ExplicitParams, or by reference using element NamedCurve. The latter 199 simply consists of an attribute named URN, which bears a uniform 200 resource name as its value. For the named curves of standards like 201 [X9.62], [FIPS-186-2] or [SEC2], the OIDs of these curves SHOULD be used 202 in this attribute, e. g. URN="urn:oid:1.2.840.10045.3.1.1". The 203 mechanism for encoding OIDs in URNs is shown in [RFC3061]. 205 Schema Definition: 207 208 209 211 212 213 214 215 216 217 219 DTD Definition: 221 222 223 225 The element ExplicitParams is used for explicit encoding of domain 226 parameters. It contains three subelements: FieldParams describes the 227 underlying field, CurveParams describes the elliptic curve, and 228 BasePointParams describes the base point of the elliptic curve. 230 Schema Definition: 232 233 234 235 236 238 239 241 DTD Definition: 243 245 3.4.2.1 Field Parameters 247 The element FieldParams is used for encoding field parameters. The 248 corresponding XML Schema type FieldParamsType is declared abstract and 249 will be extended by specialized types for prime field, characteristic 250 two field and odd characteristic extension fields parameters. 252 The XML Schema type PrimeFieldParamsType is derived from FieldParamsType 253 and is used for for encoding prime field parameters. The type contains 254 as its single subelement P, the order of the prime field. 256 The XML Schema type CharTwoFieldParamsType is derived from 257 FieldParamsType as well and is used for encoding parameters of a 258 characteristic two field. It is again an abstract type and will be 259 extended by specialized types for trinomial base fields and pentanomial 260 base fields. F2m Gaussian Normal Base fields are not supported by this 261 specification to relieve interoperability. Common to both specialized 262 types is the element M, the extension degree of the field. 264 The XML Schema type TnBFieldParamsType is derived from 265 CharTwoFieldParamsType and is used for encoding trinomial base fields. 266 It adds the single element K, which represents the integer k, where 267 x^m + x^k + 1 is the reduction polynomial. 269 The XML Schema type PnBFieldParamsType is derived from 270 CharTwoFieldParamsType as well and is used for encoding pentanomial base 271 fields. It adds the three elements K1, K2 and K3, which represent the 272 integers k1, k2 and k3 respectively, where x^m + x^k3 + x^k2 + x^k1 + 1 273 is the reduction polynomial. 275 The XML Schema type OddCharExtensionFieldParamsType is derived from 276 FieldParamsType as well and is used for encoding parameters of an 277 odd characteristic extension field. The type contains two elements M, 278 which represents the extension degree of the field m, and W, which 279 represents the integer w, where x^m - w is the reduction polynomial. 281 Schema Definition: 283 285 286 287 288 289 290 291 292 293 295 296 297 298 299 300 301 302 303 305 306 307 308 309 310 311 312 313 314 316 317 318 319 320 321 322 323 324 326 327 328 329 330 331 332 334 335 336 337 339 DTD Definition: 341 342 343 344 345 346 347 348 350 3.4.2.2 Curve Parameters 352 The element CurveParams is used for encoding parameters of the elliptic 353 curve. The corresponding XML Schema type CurveParamsType bears the 354 elements A and B representing the coefficients a and b of the elliptic 355 curve, while the optional element Seed contains the value used to derive 356 the coefficients of a randomly generated elliptic curve, according to 357 the algorithm specified in annex A3.3 of [X9.62]. 359 Schema Definition: 361 362 363 364 365 366 367 369 DTD Definition: 371 372 373 374 375 376 378 3.4.2.3 Base Point Parameters 380 The element BasePointParams is used for encoding parameters regarding 381 the base point of the elliptic curve. BasePoint represents the base 382 point itself, Order provides the order of the base point, and Cofactor 383 optionally provides the cofactor of the base point. 385 Schema Definition: 387 388 389 390 391 393 394 396 DTD Definition: 398 399 400 401 403 3.4.3 EC Points 405 The XML Schema type ECPointType is used for encoding a point on the 406 elliptic curve. It consists of the subelements X and Y, providing the 407 x and y coordinates of the point. Point compression representation is 408 not supported by this specification for the sake of simple design. 410 The point at infinity is encoded by omitting both elements X and Y. 412 The subelements X and Y are of type FieldElemType. This is an abstract 413 type for encoding elements of the elliptic curves underlying field and 414 is extended by specialized types for prime field elements and 415 characteristic two field elements. 417 The XML Schema type PrimeFieldElemType is used for encoding prime field 418 elements. It contains a single attribute named Value, whose value 419 represents the field element as an integer. 421 The XML Schema type CharTwoFieldElemType is used for encoding 422 characteristic two field elements. It contains a single attribute named 423 Value, whose value represents the field element as an octet string. The 424 octet string must be composed as shown in paragraph 2 of section 4.3.3 425 of [X9.62]. 427 The XML Schema type OddCharExtensionFieldElemType is used for encoding 428 odd characteristic extension field elements. It contains a single 429 attribute named Value, whose value represents the field element as an 430 integer. The integer must be composed as shown in section 431 5.3.3 of [IEEE1363a]. 433 Schema Definition: 435 436 437 438 439 440 441 443 444 445 446 448 449 450 452 453 454 455 457 458 459 461 462 463 464 466 467 468 470 4. Security Considerations 472 Implementers should ensure that appropriate security measures are in 473 place when they deploy ECDSA within XMLDSIG. In particular, the security 474 of ECDSA requires the careful selection of both key sizes and elliptic 475 curve domain parameters. Selection guidelines for these parameters and 476 some specific recommended curves that are considered safe are provided 477 in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion, 478 see [XMLDSIG]. 480 5. Intellectual Property Rights 482 The IETF has been notified of intellectual property rights claimed in 483 regard to the specification contained in this document. 484 For more information, consult the online list of claimed rights 485 (http://www.ietf.org/ipr.html). 487 The IETF takes no position regarding the validity or scope of any 488 intellectual property or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; neither does it represent that it 492 has made any effort to identify any such rights. Information on the 493 IETF's procedures with respect to rights in standards-track and 494 standards-related documentation can be found in BCP-11. Copies of 495 claims of rights made available for publication and any assurances of 496 licenses to be made available, or the result of an attempt made to 497 obtain a general license or permission for the use of such 498 proprietary rights by implementers or users of this specification can 499 be obtained from the IETF Secretariat. 501 6. References 503 [FIPS-180-1] Federal Information Processing Standards Publication 504 (FIPS PUB) 180-1, Secure Hash Standard, April 1995. 506 [FIPS-186-2] Federal Information Processing Standards Publication 507 (FIPS PUB) 186-2, Digital Signature Standard, January 508 2000. 510 [IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) 511 Standard 1363-2000, Standard Specifications for Public Key 512 Cryptography, January 2000. 514 [IEEE1363a] Institute for Electrical and Electronics Engineers (IEEE) 515 Standard 1363, Draft Standard Specifications for Public 516 Key Cryptography -- Amendment 1: Additional Techniques, 517 October 2002. 519 [KEYS] Lenstra, A.K. and Verheul, E.R., Selecting Cryptographic Key 520 Sizes. October 1999. Presented at Public Key Cryptography 521 Conference, Melbourne, Australia, January 2000. 522 http://www.cryptosavvy.com/ 524 [RFC3061] Mealling, M., RFC 3061, A URN Namespace of Object 525 Identifiers. IETF Informational RFC, February 2001. 526 http://www.ietf.org/rfc/rfc3061.txt 528 [RFC3279] Bassham, L., Housley, R., and Polk, W., RFC 3279, Algorithms 529 and Identifiers for the Internet X.509 Public Key 530 Infrastructure Certificate and Certificate Revocation List 531 (CRL) Profile. IETF Proposed Standard, April 2002. 532 http://www.ietf.org/rfc/rfc3279.txt 534 [SEC1] Standards for Efficient Cryptography Group, SEC 1: Elliptic 535 Curve Cryptography, Version 1.0, September 2000. 536 http://www.secg.org 538 [SEC2] Standards for Efficient Cryptography Group, SEC 2: Recommended 539 Elliptic Curve Domain Parameters, Version 1.0, September 2000. 540 http://www.secg.org 542 [X9.62] American National Standards Institute. ANSI X9.62-1998, 543 Public Key Cryptography for the Financial Services Industry: 544 The Elliptic Curve Digital Signature Algorithm. January 1999. 546 [XML] Bray, T., Maler, E., Paoli, J. , and Sperberg-McQueen, C. M., 547 Extensible Markup Language (XML) 1.0 (Second Edition), W3C 548 Recommendation, October 2000. 549 http://www.w3.org/TR/2000/REC-xml-20001006 551 [XMLDSIG] Eastlake, D., Reagle, J., and Solo, D., XML-Signature 552 Syntax and Processing. W3C Recommendation, February 2002. 553 http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 555 [XML-ns] Bray, T., Hollander, D., and Layman, A., Namespaces in XML, 556 W3C Recommendation, January 1999. 557 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 559 [XML-schema] Beech, D., Maloney, M., Mendelsohn, N., and Thompson, 560 H., XML Schema Part 1: Structures, W3C Recommendation, 561 May 2001. 562 http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ 563 Biron, P., and Malhotra, A., ML Schema Part 2: 564 Datatypes, W3C Recommendation, May 2001. 565 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 567 7. Authors' Addresses 569 Simon Blake-Wilson 570 BCI 571 96 Spadina Ave, Unit 606 572 Toronto, ON, M5V 2J6, Canada 573 e-mail: sblakewilson@bcisse.com 575 Gregor Karlinger 576 Chief Information Office Austria 577 Parkring 10/I/5 578 1010 Wien, Austria 579 e-mail: gregor.karlinger@cio.gv.at 581 Tetsutaro Kobayashi 582 NTT Laboratories 583 1-1 Hikarinooka, Yokosuka, 239-0847, Japan 584 e-mail: kotetsu@isl.ntt.co.jp 586 Yongge Wang 587 University of North Carolina at Charlotte 588 9201 University City Blvd 589 Charlotte, NC 28223, USA 590 e-mail: yonwang@uncc.edu 592 8. Acknowledgements 594 The authors would like to acknowledge the many helpful comments of 595 Wolfgang Bauer, Donald Eastlake, Tom Gindin, Chris Hawk, Akihiro Kato, 596 Shiho Moriai, Joseph M. Reagle Jr., and Francois Rousseau. 598 9. Full Copyright Statement 600 Copyright (C) The Internet Society (1999). All Rights Reserved. 602 This document and translations of it may be copied and furnished to 603 others, and derivative works that comment on or otherwise explain 604 it or assist in its implementation may be prepared, copied, 605 published and distributed, in whole or in part, without restriction 606 of any kind, provided that the above copyright notice and this 607 paragraph are included on all such copies and derivative works. 608 However, this document itself may not be modified in any way, such 609 as by removing the copyright notice or references to the Internet 610 Society or other Internet organizations, except as needed for the 611 purpose of developing Internet standards in which case the procedures 612 for copyrights defined in the Internet Standards process must be 613 followed, or as required to translate it into languages other than 614 English. 616 The limited permissions granted above are perpetual and will not be 617 revoked by the Internet Society or its successors or assigns. 619 This document and the information contained herein is provided on an 620 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 621 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 622 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 623 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 624 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Appendix A: Aggregate XML Schema 628 629 638 640 641 642 643 645 646 647 649 651 652 653 655 656 657 658 659 660 661 662 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 711 712 713 714 715 716 717 719 720 721 722 723 724 725 726 727 728 729 730 731 732 734 735 737 739 740 741 742 743 744 746 748 749 750 751 752 754 755 756 757 758 759 760 762 763 764 765 766 767 768 770 771 772 773 775 Appendix B: Aggregate DTD 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804