idnits 2.17.00 (12 Aug 2021) /tmp/idnits3881/draft-blake-wilson-xmldsig-ecdsa-07.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 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 116: '...The XML namespace [XML-ns] URI that MUST be used by implementations of...' RFC 2119 keyword, line 145: '...definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]:...' RFC 2119 keyword, line 204: '...[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 (December 2003) is 6731 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 86, but not defined == Missing Reference: 'NIST-ECC' is mentioned on line 480, 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' ** Downref: Normative reference to an Informational RFC: RFC 3061 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- 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: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Blake-Wilson, BCI 2 G. Karlinger, CIO Austria 3 T. Kobayashi, NTT 4 Y. Wang, UNCC 5 Expires: June 2004 December 2003 7 Using the Elliptic Curve Signature Algorithm (ECDSA) 8 for XML Digital Signatures 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 Normative References . . . . . . . . . . . . . . . . . . . . . . 10 58 6 Informative References . . . . . . . . . . . . . . . . . . . . . 12 59 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 61 Appendix A: Aggregate XML Schema . . . . . . . . . . . . . . . . . 13 62 Appendix B: Aggregate DTD . . . . . . . . . . . . . . . . . . . . . 16 64 Authors' addresses. . . . . . . . . . . . . . . . . . . . . . . . . 17 65 Intellectual Property Rights. . . . . . . . . . . . . . . . . . . . 17 66 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . 18 68 1. Introduction 70 This document specifies how to use the Elliptic Curve Digital Signature 71 Algorithm (ECDSA) with XML signatures as specified in [XMLDSIG]. 72 [XMLDSIG] defines only two digital signature methods: RSA signatures 73 and DSA (DSS) signatures. This document introduces ECDSA signatures as 74 an additional method. 76 This document uses both XML Schemas [XML-schema] (normative) and DTDs 77 [XML] (informational) for specifying the corresponding XML structures. 79 2. ECDSA 81 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 82 curve analogue of the DSA (DSS) signature method [FIPS186-2]. It is 83 defined in the ANSI X9.62 standard [X9.62]. Other compatible 84 specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363], 85 IEEE 1363a [IEEE1363a], and SEC1 [SEC1]. [RFC3279] describes the means 86 to carry ECDSA keys in X.509 certificates. [FIPS186-2], [SEC2], and 87 [X9.62] give recommended elliptic curve domain parameters for use with 88 ECDSA. 90 Like DSA, ECDSA incorporates the use of a hash function. Currently,the 91 only hash function defined for use with ECDSA is the SHA-1 message 92 digest algorithm [FIPS-180-1]. 94 ECDSA signatures are smaller than RSA signatures of similar 95 cryptographic strength. ECDSA public keys (and certificates) are smaller 96 than similar strength DSA keys, resulting in improved communications 97 efficiency. Furthermore, on many platforms ECDSA operations can be 98 computed faster than similar strength RSA or DSA operations (see [KEYS] 99 for a security analysis of key sizes across public key algorithms). 100 These advantages of signature size, bandwidth, and computational 101 efficiency may make ECDSA an attractive choice for XMLDSIG 102 implementations. 104 3. Specifying ECDSA within XMLDSIG 106 This section specifies the details of how to use ECDSA with XML 107 Signature Syntax and Processing [XMLDSIG]. It relies heavily on the 108 syntax and namespace defined therein. 110 3.1 Version, Namespaces and Identifiers 112 This specification makes no provision for an explicit version number in 113 the syntax. If a future version is needed, it will use a different 114 namespace. 116 The XML namespace [XML-ns] URI that MUST be used by implementations of 117 this (dated) specification is: 118 http://www.w3.org/2001/04/xmldsig-more# 120 Elements in the namespace of the [XMLDSIG] specification are marked as 121 such by using the namespace prefix "dsig" in the remaining sections of 122 this document. 124 The identifier for the ECDSA signature algorithm is: 125 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 127 3.2 XML Schema Preamble and DTD Replacement 129 3.2.1 XML Schema Preamble 131 The subsequent preamble is to be used with the XML Schema definitions 132 given in the remaining sections of this document. 134 135 142 3.2.2 DTD Replacement 144 In order to include ECDSA in XML-signature syntax, the following 145 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 147 149 3.3 ECDSA Signatures 151 The input to the ECDSA algorithm is the canonicalized representation of 152 the dsig:SignedInfo element as specified in Section 3 of [XMLDSIG]. 154 The output of the ECDSA algorithm consists of a pair of integers usually 155 referred by the pair (r, s). The signature value (text value of element 156 dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the 157 base64 encoding of the concatenation of two octet-streams that 158 respectively result from the octet-encoding of the values r and s. This 159 concatenation is described in section E3.1 of [IEEE1363]. 161 3.4 ECDSA Key Values 163 The syntax used for ECDSA key values closely follows the ASN.1 syntax 164 defined in ANSI X9.62 [X9.62]. 166 3.4.1 Key Value Root Element 168 The element ECDSAKeyValue is used for encoding ECDSA public keys. For 169 use with XMLDSIG simply use this element inside dsig:KeyValue, such as 170 the predefined elements dsig:RSAKeyValue or dsig:DSAKeyValue. 172 The element consists of an optional subelement DomainParameters and the 173 mandatory subelement PublicKey. If Domainparameters is missing in an 174 instance, this means that the application knows about them from other 175 means (implicitly). 177 Schema Definition: 179 181 182 183 185 186 187 189 DTD Definition: 191 192 193 194 195 196 198 3.4.2 EC Domain Parameters 200 Domain parameters can be encoded either explicitly using element 201 ExplicitParams, or by reference using element NamedCurve. The latter 202 simply consists of an attribute named URN, which bears a uniform 203 resource name as its value. For the named curves of standards like 204 [X9.62], [FIPS-186-2] or [SEC2], the OIDs of these curves SHOULD be used 205 in this attribute, e. g. URN="urn:oid:1.2.840.10045.3.1.1". The 206 mechanism for encoding OIDs in URNs is shown in [RFC3061]. 208 Schema Definition: 210 211 212 214 215 216 217 218 219 220 222 DTD Definition: 224 225 226 228 The element ExplicitParams is used for explicit encoding of domain 229 parameters. It contains three subelements: FieldParams describes the 230 underlying field, CurveParams describes the elliptic curve, and 231 BasePointParams describes the base point of the elliptic curve. 233 Schema Definition: 235 236 237 238 239 241 242 244 DTD Definition: 246 248 3.4.2.1 Field Parameters 250 The element FieldParams is used for encoding field parameters. The 251 corresponding XML Schema type FieldParamsType is declared abstract and 252 will be extended by specialized types for prime field, characteristic 253 two field and odd characteristic extension fields parameters. 255 The XML Schema type PrimeFieldParamsType is derived from FieldParamsType 256 and is used for for encoding prime field parameters. The type contains 257 as its single subelement P, the order of the prime field. 259 The XML Schema type CharTwoFieldParamsType is derived from 260 FieldParamsType as well and is used for encoding parameters of a 261 characteristic two field. It is again an abstract type and will be 262 extended by specialized types for trinomial base fields and pentanomial 263 base fields. F2m Gaussian Normal Base fields are not supported by this 264 specification to relieve interoperability. Common to both specialized 265 types is the element M, the extension degree of the field. 267 The XML Schema type TnBFieldParamsType is derived from 268 CharTwoFieldParamsType and is used for encoding trinomial base fields. 269 It adds the single element K, which represents the integer k, where 270 x^m + x^k + 1 is the reduction polynomial. 272 The XML Schema type PnBFieldParamsType is derived from 273 CharTwoFieldParamsType as well and is used for encoding pentanomial base 274 fields. It adds the three elements K1, K2 and K3, which represent the 275 integers k1, k2 and k3 respectively, where x^m + x^k3 + x^k2 + x^k1 + 1 276 is the reduction polynomial. 278 The XML Schema type OddCharExtensionFieldParamsType is derived from 279 FieldParamsType as well and is used for encoding parameters of an 280 odd characteristic extension field. The type contains two elements M, 281 which represents the extension degree of the field m, and W, which 282 represents the integer w, where x^m - w is the reduction polynomial. 284 Schema Definition: 286 288 289 290 291 292 293 294 295 296 298 299 300 301 302 303 304 305 306 308 309 310 311 312 313 314 315 316 317 319 320 321 322 323 324 325 326 327 329 330 331 332 333 334 335 337 338 339 340 342 DTD Definition: 344 345 346 347 348 349 350 351 353 3.4.2.2 Curve Parameters 355 The element CurveParams is used for encoding parameters of the elliptic 356 curve. The corresponding XML Schema type CurveParamsType bears the 357 elements A and B representing the coefficients a and b of the elliptic 358 curve, while the optional element Seed contains the value used to derive 359 the coefficients of a randomly generated elliptic curve, according to 360 the algorithm specified in annex A3.3 of [X9.62]. 362 Schema Definition: 364 365 366 367 368 369 370 372 DTD Definition: 374 375 376 377 378 379 381 3.4.2.3 Base Point Parameters 383 The element BasePointParams is used for encoding parameters regarding 384 the base point of the elliptic curve. BasePoint represents the base 385 point itself, Order provides the order of the base point, and Cofactor 386 optionally provides the cofactor of the base point. 388 Schema Definition: 390 391 392 393 394 396 397 399 DTD Definition: 401 402 403 404 406 3.4.3 EC Points 408 The XML Schema type ECPointType is used for encoding a point on the 409 elliptic curve. It consists of the subelements X and Y, providing the 410 x and y coordinates of the point. Point compression representation is 411 not supported by this specification for the sake of simple design. 413 The point at infinity is encoded by omitting both elements X and Y. 415 The subelements X and Y are of type FieldElemType. This is an abstract 416 type for encoding elements of the elliptic curves underlying field and 417 is extended by specialized types for prime field elements and 418 characteristic two field elements. 420 The XML Schema type PrimeFieldElemType is used for encoding prime field 421 elements. It contains a single attribute named Value, whose value 422 represents the field element as an integer. 424 The XML Schema type CharTwoFieldElemType is used for encoding 425 characteristic two field elements. It contains a single attribute named 426 Value, whose value represents the field element as an octet string. The 427 octet string must be composed as shown in paragraph 2 of section 4.3.3 428 of [X9.62]. 430 The XML Schema type OddCharExtensionFieldElemType is used for encoding 431 odd characteristic extension field elements. It contains a single 432 attribute named Value, whose value represents the field element as an 433 integer. The integer must be composed as shown in section 434 5.3.3 of [IEEE1363a]. 436 Schema Definition: 438 439 440 441 442 443 444 446 447 448 449 451 452 453 455 456 457 458 460 461 462 464 465 466 467 469 470 471 473 4. Security Considerations 475 Implementers should ensure that appropriate security measures are in 476 place when they deploy ECDSA within XMLDSIG. In particular, the security 477 of ECDSA requires the careful selection of both key sizes and elliptic 478 curve domain parameters. Selection guidelines for these parameters and 479 some specific recommended curves that are considered safe are provided 480 in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion, 481 see [XMLDSIG]. 483 5. Normative References 485 [FIPS-180-1] Federal Information Processing Standards Publication 486 (FIPS PUB) 180-1, Secure Hash Standard, April 1995. 488 [FIPS-186-2] Federal Information Processing Standards Publication 489 (FIPS PUB) 186-2, Digital Signature Standard, January 490 2000. 492 [IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) 493 Standard 1363-2000, Standard Specifications for Public Key 494 Cryptography, January 2000. 496 [IEEE1363a] Institute for Electrical and Electronics Engineers (IEEE) 497 Standard 1363, Draft Standard Specifications for Public 498 Key Cryptography -- Amendment 1: Additional Techniques, 499 October 2002. 501 [RFC3061] Mealling, M., RFC 3061, A URN Namespace of Object 502 Identifiers. IETF Informational RFC, February 2001. 503 http://www.ietf.org/rfc/rfc3061.txt 505 [RFC3279] Bassham, L., Housley, R., and Polk, W., RFC 3279, Algorithms 506 and Identifiers for the Internet X.509 Public Key 507 Infrastructure Certificate and Certificate Revocation List 508 (CRL) Profile. IETF Proposed Standard, April 2002. 509 http://www.ietf.org/rfc/rfc3279.txt 511 [SEC1] Standards for Efficient Cryptography Group, SEC 1: Elliptic 512 Curve Cryptography, Version 1.0, September 2000. 513 http://www.secg.org 515 [X9.62] American National Standards Institute. ANSI X9.62-1998, 516 Public Key Cryptography for the Financial Services Industry: 517 The Elliptic Curve Digital Signature Algorithm. January 1999. 519 [XMLDSIG] Eastlake, D., Reagle, J., and Solo, D., XML-Signature 520 Syntax and Processing. W3C Recommendation, February 2002. 521 http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 523 [XML-ns] Bray, T., Hollander, D., and Layman, A., Namespaces in XML, 524 W3C Recommendation, January 1999. 525 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 527 [XML-schema] Beech, D., Maloney, M., Mendelsohn, N., and Thompson, 528 H., XML Schema Part 1: Structures, W3C Recommendation, 529 May 2001. 530 http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ 531 Biron, P., and Malhotra, A., ML Schema Part 2: 532 Datatypes, W3C Recommendation, May 2001. 533 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 535 6. Informative References 537 [KEYS] Lenstra, A.K. and Verheul, E.R., Selecting Cryptographic Key 538 Sizes. October 1999. Presented at Public Key Cryptography 539 Conference, Melbourne, Australia, January 2000. 540 http://www.cryptosavvy.com/ 542 [SEC2] Standards for Efficient Cryptography Group, SEC 2: Recommended 543 Elliptic Curve Domain Parameters, Version 1.0, September 2000. 544 http://www.secg.org 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 7. Acknowledgements 553 The authors would like to acknowledge the many helpful comments of 554 Wolfgang Bauer, Donald Eastlake, Tom Gindin, Chris Hawk, Akihiro Kato, 555 Shiho Moriai, Joseph M. Reagle Jr., and Francois Rousseau. 557 Appendix A: Aggregate XML Schema 559 560 569 571 572 573 574 576 577 578 580 582 583 584 586 587 588 589 590 591 592 593 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 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 649 650 651 652 653 654 655 656 657 658 659 660 661 662 664 665 667 669 670 671 672 673 674 676 678 679 680 681 682 684 685 686 687 688 689 690 692 693 694 695 696 697 698 700 701 702 703 705 Appendix B: Aggregate DTD 707 708 709 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 736 Authors' Addresses 738 Simon Blake-Wilson 739 BCI 740 96 Spadina Ave, Unit 606 741 Toronto, ON, M5V 2J6, Canada 742 e-mail: sblakewilson@bcisse.com 744 Gregor Karlinger 745 Federal Staff Office for IT Strategies/Federal Chancellery 746 Ballhausplatz 2 747 1014 Wien, Austria 748 e-mail: gregor.karlinger@cio.gv.at 750 Tetsutaro Kobayashi 751 NTT Laboratories 752 1-1 Hikarinooka, Yokosuka, 239-0847, Japan 753 e-mail: kotetsu@isl.ntt.co.jp 755 Yongge Wang 756 University of North Carolina at Charlotte 757 9201 University City Blvd 758 Charlotte, NC 28223, USA 759 e-mail: yonwang@uncc.edu 761 Intellectual Property Rights 763 The IETF has been notified of intellectual property rights claimed in 764 regard to the specification contained in this document. 765 For more information, consult the online list of claimed rights 766 (http://www.ietf.org/ipr.html). 768 The IETF takes no position regarding the validity or scope of any 769 intellectual property or other rights that might be claimed to 770 pertain to the implementation or use of the technology described in 771 this document or the extent to which any license under such rights 772 might or might not be available; neither does it represent that it 773 has made any effort to identify any such rights. Information on the 774 IETF's procedures with respect to rights in standards-track and 775 standards-related documentation can be found in BCP-11. Copies of 776 claims of rights made available for publication and any assurances of 777 licenses to be made available, or the result of an attempt made to 778 obtain a general license or permission for the use of such 779 proprietary rights by implementers or users of this specification can 780 be obtained from the IETF Secretariat. 782 Full Copyright Statement 784 Copyright (C) The Internet Society (1999). All Rights Reserved. 785 This document and translations of it may be copied and furnished to 786 others, and derivative works that comment on or otherwise explain 787 it or assist in its implementation may be prepared, copied, 788 published and distributed, in whole or in part, without restriction 789 of any kind, provided that the above copyright notice and this 790 paragraph are included on all such copies and derivative works. 791 However, this document itself may not be modified in any way, such 792 as by removing the copyright notice or references to the Internet 793 Society or other Internet organizations, except as needed for the 794 purpose of developing Internet standards in which case the procedures 795 for copyrights defined in the Internet Standards process must be 796 followed, or as required to translate it into languages other than 797 English. 799 The limited permissions granted above are perpetual and will not be 800 revoked by the Internet Society or its successors or assigns. 802 This document and the information contained herein is provided on an 803 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 804 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 805 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 806 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 807 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.