summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4050.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4050.txt')
-rw-r--r--doc/rfc/rfc4050.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc4050.txt b/doc/rfc/rfc4050.txt
new file mode 100644
index 0000000..c849ee7
--- /dev/null
+++ b/doc/rfc/rfc4050.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. ECDSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Specifying ECDSA within XMLDSIG . . . . . . . . . . . . . . . 3
+ 3.1. Version, Namespaces, and Identifiers . . . . . . . . . . 3
+ 3.2. XML Schema Preamble and DTD Replacement. . . . . . . . . 4
+ 3.2.1. XML Schema Preamble. . . . . . . . . . . . . . . 4
+ 3.2.2. DTD Replacement. . . . . . . . . . . . . . . . . 4
+ 3.3. ECDSA Signatures . . . . . . . . . . . . . . . . . . . . 4
+ 3.4. ECDSA Key Values . . . . . . . . . . . . . . . . . . . . 4
+ 3.4.1. Key Value Root Element . . . . . . . . . . . . . 4
+ 3.4.2. EC Domain Parameters . . . . . . . . . . . . . . 5
+ 3.4.2.1. Field Parameters . . . . . . . . . . . 6
+ 3.4.2.2. Curve Parameters . . . . . . . . . . . 8
+ 3.4.2.3. Base Point Parameters. . . . . . . . . 9
+ 3.4.3. EC Points . . . . . . . . . . . . . . . . . . . 10
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11
+ 6. Informative References . . . . . . . . . . . . . . . . . . . . 12
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+ Appendix A: Aggregate XML Schema . . . . . . . . . . . . . . . . . 14
+ Appendix B: Aggregate DTD. . . . . . . . . . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+ 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.
+
+2. ECDSA
+
+ 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.
+
+3. Specifying ECDSA within XMLDSIG
+
+ 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].
+
+3.1. Version, Namespaces, and Identifiers
+
+ This specification makes no provision for an explicit version number
+ in the syntax. If a future version is needed, it will use a
+ different namespace.
+
+ The XML namespace [XML-ns] URI that MUST be used by implementations
+ of this (dated) specification is:
+
+ http://www.w3.org/2001/04/xmldsig-more#
+
+ Elements in the namespace of the [XMLDSIG] specification are marked
+ by using the namespace prefix "dsig" in the remaining sections of
+ this document.
+
+ The identifier for the ECDSA signature algorithm as defined in
+ [Eastlake] is:
+
+ http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1
+
+
+
+
+
+
+
+
+
+
+
+
+Blake-Wilson, et al. Informational [Page 3]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+3.2. XML Schema Preamble and DTD Replacement
+
+3.2.1. XML Schema Preamble
+
+ The subsequent preamble is to be used with the XML Schema definitions
+ given in the remaining sections of this document.
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema
+ targetNamespace="http://www.w3.org/2001/04/xmldsig-more#"
+ xmlns:ecdsa="http://www.w3.org/2001/04/xmldsig-more#"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified" attributeFormDefault="unqualified"
+ version="0.2">
+
+3.2.2. DTD Replacement
+
+ To include ECDSA in XML-signature syntax, the following definition of
+ the entity Key.ANY SHOULD replace the one in [XMLDSIG]:
+
+ <!ENTITY % KeyValue.ANY '| ecdsa:ECDSAKeyValue'>
+
+3.3. ECDSA Signatures
+
+ 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].
+
+3.4. ECDSA Key Values
+
+ The syntax used for ECDSA key values closely follows the ASN.1 syntax
+ defined in ANSI X9.62 [X9.62].
+
+3.4.1. Key Value Root Element
+
+ 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.
+
+Schema Definition:
+
+ <xs:element name="ECDSAKeyValue" type="ecdsa:ECDSAKeyValueType"/>
+ <xs:complexType name="ECDSAKeyValueType">
+ <xs:sequence>
+ <xs:element name="DomainParameters" type="ecdsa:DomainParamsType"
+ minOccurs="0"/>
+ <xs:element name="PublicKey" type="ecdsa:ECPointType"/>
+ </xs:sequence>
+ </xs:complexType>
+
+DTD Definition:
+
+ <!ELEMENT ECDSAKeyValue (DomainParameters?, PublicKey)>
+ <!ELEMENT PublicKey (X, Y)?>
+ <!ELEMENT X EMPTY>
+ <!ATTLIST X Value CDATA #REQUIRED>
+ <!ELEMENT Y EMPTY>
+ <!ATTLIST Y Value CDATA #REQUIRED>
+
+3.4.2. EC Domain Parameters
+
+ 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].
+
+ Schema Definition:
+
+ <xs:complexType name="DomainParamsType">
+ <xs:choice>
+ <xs:element name="ExplicitParams"
+ type="ecdsa:ExplicitParamsType"/>
+ <xs:element name="NamedCurve">
+ <xs:complexType>
+ <xs:attribute name="URN" type="xs:anyURI" use="required"/>
+ </xs:complexType>
+ </xs:element>
+ </xs:choice>
+ </xs:complexType>
+
+
+
+
+Blake-Wilson, et al. Informational [Page 5]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+ DTD Definition:
+
+ <!ELEMENT DomainParameters (ExplicitParams | NamedCurve)>
+ <!ELEMENT NamedCurve EMPTY>
+ <!ATTLIST NamedCurve URN CDATA #REQUIRED>
+
+ 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.
+
+Schema Definition:
+
+ <xs:complexType name="ExplicitParamsType">
+ <xs:sequence>
+ <xs:element name="FieldParams" type="ecdsa:FieldParamsType"/>
+ <xs:element name="CurveParams" type="ecdsa:CurveParamsType"/>
+ <xs:element name="BasePointParams"
+ type="ecdsa:BasePointParamsType"/>
+ </xs:sequence>
+ </xs:complexType>
+
+DTD Definition:
+
+ <!ELEMENT ExplicitParams (FieldParams, CurveParams, BasePointParams)>
+
+3.4.2.1. Field Parameters
+
+ 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.
+
+ Schema Definition:
+
+ <xs:complexType name="FieldParamsType" abstract="true"/>
+
+ <xs:complexType name="PrimeFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldParamsType">
+ <xs:sequence>
+ <xs:element name="P" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:complexType name="CharTwoFieldParamsType" abstract="true">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldParamsType">
+ <xs:sequence>
+ <xs:element name="M" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:complexType name="OddCharExtensionFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldParamsType">
+ <xs:sequence>
+ <xs:element name="M" type="xs:positiveInteger"/>
+ <xs:element name="W" type="xs:positiveInteger"/>
+ </xs:sequence>
+
+
+
+Blake-Wilson, et al. Informational [Page 7]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:complexType name="TnBFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:CharTwoFieldParamsType">
+ <xs:sequence>
+ <xs:element name="K" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:complexType name="PnBFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:CharTwoFieldParamsType">
+ <xs:sequence>
+ <xs:element name="K1" type="xs:positiveInteger"/>
+ <xs:element name="K2" type="xs:positiveInteger"/>
+ <xs:element name="K3" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ DTD Definition:
+
+ <!ELEMENT FieldParams (P | (M, K) | (M, K1, K2, K3) | (M, W))>
+ <!ELEMENT P (#PCDATA)>
+ <!ELEMENT M (#PCDATA)>
+ <!ELEMENT K (#PCDATA)>
+ <!ELEMENT K1 (#PCDATA)>
+ <!ELEMENT K2 (#PCDATA)>
+ <!ELEMENT K3 (#PCDATA)>
+ <!ELEMENT W (#PCDATA)>
+
+3.4.2.2. Curve Parameters
+
+ 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
+
+
+ Schema Definition:
+
+ <xs:complexType name="CurveParamsType">
+ <xs:sequence>
+ <xs:element name="A" type="ecdsa:FieldElemType"/>
+ <xs:element name="B" type="ecdsa:FieldElemType"/>
+ <xs:element name="Seed" type="xs:hexBinary" minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ DTD Definition:
+
+ <!ELEMENT CurveParams (A, B, Seed?)>
+ <!ELEMENT A EMPTY>
+ <!ATTLIST A Value CDATA #REQUIRED>
+ <!ELEMENT B EMPTY>
+ <!ATTLIST B Value CDATA #REQUIRED>
+ <!ELEMENT Seed (#PCDATA)>
+
+3.4.2.3. Base Point Parameters
+
+ 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.
+
+ Schema Definition:
+
+ <xs:complexType name="BasePointParamsType">
+ <xs:sequence>
+ <xs:element name="BasePoint" type="ecdsa:ECPointType"/>
+ <xs:element name="Order" type="xs:positiveInteger"/>
+ <xs:element name="Cofactor" type="xs:positiveInteger"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ DTD Definition:
+
+ <!ELEMENT BasePointParams (BasePoint, Order, Cofactor?)>
+ <!ELEMENT BasePoint (X, Y)?>
+ <!ELEMENT Order (#PCDATA)>
+ <!ELEMENT Cofactor (#PCDATA)>
+
+
+
+
+
+
+
+
+Blake-Wilson, et al. Informational [Page 9]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+3.4.3. EC Points
+
+ 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].
+
+ Schema Definition:
+
+ <xs:complexType name="ECPointType">
+ <xs:sequence minOccurs="0">
+ <xs:element name="X" type="ecdsa:FieldElemType"/>
+ <xs:element name="Y" type="ecdsa:FieldElemType"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="FieldElemType" abstract="true"/>
+
+
+
+
+
+
+
+
+
+
+
+Blake-Wilson, et al. Informational [Page 10]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+ <xs:complexType name="PrimeFieldElemType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldElemType">
+ <xs:attribute name="Value" type="xs:nonNegativeInteger"
+ use="required"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:complexType name="CharTwoFieldElemType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldElemType">
+ <xs:attribute name="Value" type="xs:hexBinary"
+ use="required"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:complexType name="OddCharExtensionFieldElemType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldElemType">
+ <xs:attribute name="Value" type="xs:nonNegativeInteger"
+ use="required"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+4. Security Considerations
+
+ 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].
+
+5. Normative References
+
+ [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.
+
+ [XML-schema] Beech, D., Maloney, M., Mendelsohn, N., and Thompson,
+ H., XML Schema Part 1: Structures, W3C Recommendation,
+ May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-
+ 20010502/ Biron, P., and Malhotra, A., ML Schema Part 2:
+ Datatypes, W3C Recommendation, May 2001.
+ http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
+
+6. Informative References
+
+ [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
+
+ [XML-ns] Bray, T., Hollander, D., and Layman, A., Namespaces in
+ XML, W3C Recommendation, January 1999.
+ http://www.w3.org/TR/1999/REC-xml-names-19990114/
+
+7. Acknowledgements
+
+ 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
+
+
+Appendix A. Aggregate XML Schema
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema
+ targetNamespace="http://www.w3.org/2001/04/xmldsig-more#"
+ xmlns:ecdsa="http://www.w3.org/2001/04/xmldsig-more#"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified"
+ attributeFormDefault="unqualified"
+ version="0.2">
+
+ <!--ECDSA key value root element-->
+
+ <xs:element name="ECDSAKeyValue" type="ecdsa:ECDSAKeyValueType"/>
+ <xs:complexType name="ECDSAKeyValueType">
+ <xs:sequence>
+ <xs:element name="DomainParameters"
+ type="ecdsa:DomainParamsType" minOccurs="0"/>
+ <xs:element name="PublicKey" type="ecdsa:ECPointType"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!--EC domain parameters-->
+
+ <xs:complexType name="DomainParamsType">
+ <xs:choice>
+ <xs:element name="ExplicitParams"
+ type="ecdsa:ExplicitParamsType"/>
+ <xs:element name="NamedCurve">
+ <xs:complexType>
+ <xs:attribute name="URN" type="xs:anyURI" use="required"/>
+ </xs:complexType>
+ </xs:element>
+ </xs:choice>
+ </xs:complexType>
+ <xs:complexType name="FieldParamsType" abstract="true"/>
+
+ <xs:complexType name="PrimeFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldParamsType">
+ <xs:sequence>
+ <xs:element name="P" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="CharTwoFieldParamsType" abstract="true">
+ <xs:complexContent>
+
+
+
+Blake-Wilson, et al. Informational [Page 14]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+ <xs:extension base="ecdsa:FieldParamsType">
+ <xs:sequence>
+ <xs:element name="M" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="OddCharExtensionFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldParamsType">
+ <xs:sequence>
+ <xs:element name="M" type="xs:positiveInteger"/>
+ <xs:element name="W" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="TnBFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:CharTwoFieldParamsType">
+ <xs:sequence>
+ <xs:element name="K" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="PnBFieldParamsType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:CharTwoFieldParamsType">
+ <xs:sequence>
+ <xs:element name="K1" type="xs:positiveInteger"/>
+ <xs:element name="K2" type="xs:positiveInteger"/>
+ <xs:element name="K3" type="xs:positiveInteger"/>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="ExplicitParamsType">
+ <xs:sequence>
+ <xs:element name="FieldParams" type="ecdsa:FieldParamsType"/>
+ <xs:element name="CurveParams" type="ecdsa:CurveParamsType"/>
+ <xs:element name="BasePointParams"
+ type="ecdsa:BasePointParamsType"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="CurveParamsType">
+ <xs:sequence>
+ <xs:element name="A" type="ecdsa:FieldElemType"/>
+
+
+
+Blake-Wilson, et al. Informational [Page 15]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+ <xs:element name="B" type="ecdsa:FieldElemType"/>
+ <xs:element name="Seed" type="xs:hexBinary" minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="BasePointParamsType">
+ <xs:sequence>
+ <xs:element name="BasePoint" type="ecdsa:ECPointType"/>
+ <xs:element name="Order" type="xs:positiveInteger"/>
+ <xs:element name="Cofactor" type="xs:positiveInteger"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!--EC point-->
+
+ <xs:complexType name="ECPointType">
+ <xs:sequence minOccurs="0">
+ <xs:element name="X" type="ecdsa:FieldElemType"/>
+ <xs:element name="Y" type="ecdsa:FieldElemType"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!--Field element-->
+
+ <xs:complexType name="FieldElemType" abstract="true"/>
+ <xs:complexType name="PrimeFieldElemType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldElemType">
+ <xs:attribute name="Value" type="xs:nonNegativeInteger"
+ use="required"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="CharTwoFieldElemType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldElemType">
+ <xs:attribute name="Value" type="xs:hexBinary"
+ use="required"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:complexType name="OddCharExtensionFieldElemType">
+ <xs:complexContent>
+ <xs:extension base="ecdsa:FieldElemType">
+ <xs:attribute name="Value" type="xs:nonNegativeInteger"
+ use="required"/>
+ </xs:extension>
+ </xs:complexContent>
+
+
+
+Blake-Wilson, et al. Informational [Page 16]
+
+RFC 4050 ECDSA for XML Digital Signatures April 2005
+
+
+ </xs:complexType>
+ </xs:schema>
+
+Appendix B. Aggregate DTD
+
+ <!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.
+
+
+
+
+
+
+
+Blake-Wilson, et al. Informational [Page 19]
+