Network Working Group S. Blake-Wilson Request for Comments: 4050 BCI Category: Informational G. Karlinger CIO Austria T. Kobayashi NTT Y. Wang UNCC April 2005
Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
Abstract
This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference.
Blake-Wilson, et al. Informational [Page 1]
RFC 4050 ECDSA for XML Digital Signatures April 2005
This document specifies how to use the Elliptic Curve Digital Signature Algorithm (ECDSA) with XML signatures, as specified in [XMLDSIG]. [XMLDSIG] defines only two digital signature methods: RSA and DSA (DSS) signatures. This document introduces ECDSA signatures as an additional method.
This document uses both XML Schemas [XML-schema] (normative) and DTDs [XML] (informational) to specify the corresponding XML structures.
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic curve analogue of the DSA (DSS) signature method [FIPS-186-2]. It is defined in the ANSI X9.62 standard [X9.62]. Other compatible specifications include FIPS 186-2 [FIPS-186-2], IEEE 1363 [IEEE1363], IEEE 1363a [IEEE1363a], and SEC1 [SEC1]. [RFC3279] describes ways to carry ECDSA keys in X.509 certificates. [FIPS-186-2], [SEC2], and [X9.62] provide recommended elliptic curve domain parameters for use with ECDSA.
Blake-Wilson, et al. Informational [Page 2]
RFC 4050 ECDSA for XML Digital Signatures April 2005
Like DSA, ECDSA incorporates the use of a hash function. Currently, the only hash function defined for use with ECDSA is the SHA-1 message digest algorithm [FIPS-180-1].
ECDSA signatures are smaller than RSA signatures of similar cryptographic strength. ECDSA public keys (and certificates) are smaller than similar strength DSA keys and result in improved communication efficiency. On many platforms, ECDSA operations can be computed faster than similar strength RSA or DSA operations (see [KEYS] for a security analysis of key sizes across public key algorithms). These advantages of signature size, bandwidth, and computational efficiency may make ECDSA an attractive choice for XMLDSIG implementations.
This section specifies how to use ECDSA with XML Signature Syntax and Processing [XMLDSIG]. It relies heavily on the syntax and namespace defined in [XMLDSIG].
The input to the ECDSA algorithm is the canonicalized representation of the dsig:SignedInfo element as specified in Section 3 of [XMLDSIG].
The output of the ECDSA algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value (text value of element dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the base64 encoding of the concatenation of two octet- streams that respectively result from the octet-encoding of the values r and s. This concatenation is described in section E3.1 of [IEEE1363].
The element ECDSAKeyValue is used for encoding ECDSA public keys. For use with XMLDSIG, simply use this element inside dsig:KeyValue (such as the predefined elements dsig:RSAKeyValue or dsig:DSAKeyValue).
Blake-Wilson, et al. Informational [Page 4]
RFC 4050 ECDSA for XML Digital Signatures April 2005
The element consists of an optional subelement DomainParameters and the mandatory subelement PublicKey. If Domainparameters is missing, the application implicitly knows about it from other means.
<!ELEMENT ECDSAKeyValue (DomainParameters?, PublicKey)> <!ELEMENT PublicKey (X, Y)?> <!ELEMENT X EMPTY> <!ATTLIST X Value CDATA #REQUIRED> <!ELEMENT Y EMPTY> <!ATTLIST Y Value CDATA #REQUIRED>
Domain parameters can be encoded either explicitly using element ExplicitParams, or by reference using element NamedCurve. The latter simply consists of an attribute named URN, which bears a uniform resource name as its value. For the named curves of standards like [X9.62], [FIPS-186-2], or [SEC2], the OIDs of these curves SHOULD be used in this attribute, e.g., URN="urn:oid:1.2.840.10045.3.1.1". The mechanism for encoding OIDs in URNs is shown in [RFC3061].
The element ExplicitParams is used for explicit encoding of domain parameters. It contains three subelements: FieldParams describes the underlying field, CurveParams describes the elliptic curve, and BasePointParams describes the base point of the elliptic curve.
The element FieldParams is used for encoding field parameters. The corresponding XML Schema type FieldParamsType is declared abstract and will be extended by specialized types for prime field, characteristic two field, and odd characteristic extension fields parameters.
The XML Schema type PrimeFieldParamsType is derived from the FieldParamsType and is used for encoding prime field parameters. The type contains the order of the prime field as its single subelement P.
The XML Schema type CharTwoFieldParamsType is derived from FieldParamsType and is used for encoding parameters of a characteristic two field. It is again an abstract type and will be extended by specialized types for trinomial and pentanomial base fields. F2m Gaussian Normal Base fields are not supported by this specification to relieve interoperability. Common to both specialized types is the element M, the extension degree of the field.
Blake-Wilson, et al. Informational [Page 6]
RFC 4050 ECDSA for XML Digital Signatures April 2005
The XML Schema type TnBFieldParamsType is derived from the CharTwoFieldParamsType and is used for encoding trinomial base fields. It adds the single element K, which represents the integer k, where x^m + x^k + 1 is the reduction polynomial.
The XML Schema type PnBFieldParamsType is derived from the CharTwoFieldParamsType and is used for encoding pentanomial base fields. It adds the three elements K1, K2 and K3, which represent the integers k1, k2 and k3 respectively, where x^m + x^k3 + x^k2 + x^k1 + 1 is the reduction polynomial.
The XML Schema type OddCharExtensionFieldParamsType is derived from the FieldParamsType and is used for encoding parameters of an odd characteristic extension field. This type contains two elements: M, which represents the extension degree of the field m, and W, which represents the integer w, where x^m - w is the reduction polynomial.
The element CurveParams is used for encoding parameters of the elliptic curve. The corresponding XML Schema type CurveParamsType bears the elements A and B representing the coefficients a and b of the elliptic curve. According to the algorithm specified in annex A3.3 of [X9.62], the optional element Seed contains the value used to derive the coefficients of a randomly generated elliptic curve.
Blake-Wilson, et al. Informational [Page 8]
RFC 4050 ECDSA for XML Digital Signatures April 2005
<!ELEMENT CurveParams (A, B, Seed?)> <!ELEMENT A EMPTY> <!ATTLIST A Value CDATA #REQUIRED> <!ELEMENT B EMPTY> <!ATTLIST B Value CDATA #REQUIRED> <!ELEMENT Seed (#PCDATA)>
The element BasePointParams is used for encoding parameters regarding the base point of the elliptic curve. BasePoint represents the base point itself, Order provides the order of the base point, and Cofactor optionally provides the cofactor of the base point.
The XML Schema type ECPointType is used for encoding a point on the elliptic curve. It consists of the subelements X and Y, providing the x and y coordinates of the point. Point compression representation is not supported by this specification for the sake of simple design.
The point at infinity is encoded by omitting both elements X and Y.
The subelements X and Y are of type FieldElemType. This is an abstract type for encoding elements of the elliptic curves underlying field and is extended by specialized types for prime field elements and characteristic two field elements.
The XML Schema type PrimeFieldElemType is used for encoding prime field elements. It contains a single attribute named Value whose value represents the field element as an integer.
The XML Schema type CharTwoFieldElemType is used for encoding characteristic two field elements. It contains a single attribute named Value whose value represents the field element as an octet string. The octet string must be composed as shown in paragraph 2 of section 4.3.3 of [X9.62].
The XML Schema type OddCharExtensionFieldElemType is used for encoding odd characteristic extension field elements. It contains a single attribute named Value whose value represents the field element as an integer. The integer must be composed as shown in section 5.3.3 of [IEEE1363a].
Implementers should ensure that appropriate security measures are in place when they deploy ECDSA within XMLDSIG. In particular, the security of ECDSA requires careful selection of both key sizes and elliptic curve domain parameters. Selection guidelines for these parameters and some specific recommended curves that are considered safe are provided in [X9.62], [FIPS-186-2], and [SEC2]. For further security discussion, see [XMLDSIG].
[Eastlake] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[X9.62] American National Standards Institute. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. January 1999.
Blake-Wilson, et al. Informational [Page 11]
RFC 4050 ECDSA for XML Digital Signatures April 2005
[XMLDSIG] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[FIPS-180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, April 1995.
[FIPS-186-2] Federal Information Processing Standards Publication (FIPS PUB) 186-2, Digital Signature Standard, January 2000.
[IEEE1363] Institute for Electrical and Electronics Engineers (IEEE) Standard 1363-2000, Standard Specifications for Public Key Cryptography, January 2000.
[IEEE1363a] Institute for Electrical and Electronics Engineers (IEEE) Standard 1363, Draft Standard Specifications for Public Key Cryptography -- Amendment 1: Additional Techniques, October 2002.
[KEYS] Lenstra, A.K. and Verheul, E.R., Selecting Cryptographic Key Sizes. October 1999. Presented at Public Key Cryptography Conference, Melbourne, Australia, January 2000. http://www.cryptosavvy.com/
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[SEC1] Standards for Efficient Cryptography Group, SEC 1: Elliptic Curve Cryptography, Version 1.0, September 2000. http://www.secg.org
Blake-Wilson, et al. Informational [Page 12]
RFC 4050 ECDSA for XML Digital Signatures April 2005
[SEC2] Standards for Efficient Cryptography Group, SEC 2: Recommended Elliptic Curve Domain Parameters, Version 1.0, September 2000. http://www.secg.org
[XML] Bray, T., Maler, E., Paoli, J., and Sperberg-McQueen, C. M., Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, October 2000. http://www.w3.org/TR/2000/REC-xml-20001006
The authors would like to acknowledge the many helpful comments of Wolfgang Bauer, Donald Eastlake, Tom Gindin, Chris Hawk, Akihiro Kato, Shiho Moriai, Joseph M. Reagle Jr., and Francois Rousseau.
Blake-Wilson, et al. Informational [Page 13]
RFC 4050 ECDSA for XML Digital Signatures April 2005
<!ELEMENT ECDSAKeyValue (DomainParameters?, PublicKey)> <!ELEMENT PublicKey (X, Y)?> <!ELEMENT X EMPTY> <!ATTLIST X Value CDATA #REQUIRED> <!ELEMENT Y EMPTY> <!ATTLIST Y Value CDATA #REQUIRED> <!ELEMENT DomainParameters (ExplicitParams | NamedCurve)> <!ELEMENT NamedCurve EMPTY> <!ATTLIST NamedCurve URN CDATA #REQUIRED> <!ELEMENT ExplicitParams (FieldParams, CurveParams, BasePointParams)> <!ELEMENT FieldParams (P | (M, K) | (M, K1, K2, K3) | (M, W))> <!ELEMENT P (#PCDATA)> <!ELEMENT M (#PCDATA)> <!ELEMENT W (#PCDATA)> <!ELEMENT K (#PCDATA)> <!ELEMENT K1 (#PCDATA)> <!ELEMENT K2 (#PCDATA)> <!ELEMENT K3 (#PCDATA)> <!ELEMENT CurveParams (A, B, Seed?)> <!ELEMENT A EMPTY> <!ATTLIST A Value CDATA #REQUIRED> <!ELEMENT B EMPTY> <!ATTLIST B Value CDATA #REQUIRED> <!ELEMENT Seed (#PCDATA)> <!ELEMENT BasePointParams (BasePoint, Order, Cofactor?)> <!ELEMENT BasePoint (X, Y)?> <!ELEMENT Order (#PCDATA)> <!ELEMENT Cofactor (#PCDATA)>
Blake-Wilson, et al. Informational [Page 17]
RFC 4050 ECDSA for XML Digital Signatures April 2005
Authors' Addresses
Simon Blake-Wilson BCI 96 Spadina Ave, Unit 606 Toronto, ON, M5V 2J6, Canada
EMail: sblakewilson@bcisse.com
Gregor Karlinger Federal Staff Office for IT Strategies/Federal Chancellery Ballhausplatz 2 1014 Wien, Austria
EMail: gregor.karlinger@cio.gv.at
Tetsutaro Kobayashi NTT Laboratories 1-1 Hikarinooka, Yokosuka, 239-0847, Japan
EMail: kotetsu@isl.ntt.co.jp
Yongge Wang University of North Carolina at Charlotte 9201 University City Blvd Charlotte, NC 28223, USA
EMail: yonwang@uncc.edu
Blake-Wilson, et al. Informational [Page 18]
RFC 4050 ECDSA for XML Digital Signatures April 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.