< draft-blake-wilson-xmldsig-ecdsa-02.txt		draft-blake-wilson-xmldsig-ecdsa-03.txt >
	S. Blake-Wilson and Y.Wang		S. Blake-Wilson, BCI
	INTERNET-DRAFT Certicom Corp.		G. Karlinger, CIO Austria
	Expires: 19 September 2001 20 March 2001		INTERNET-DRAFT Y. Wang, UNCC
			Expires: 31 December 2002 30 June 2002
	ECDSA with XML-Signature Syntax		ECDSA with XML-Signature Syntax
	<draft-blake-wilson-xmldsig-ecdsa-02.txt>		<draft-blake-wilson-xmldsig-ecdsa-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026. Internet-Drafts are working		provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 32 ¶
	The list of current Internet-Drafts may be found at		The list of current Internet-Drafts may be found at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories may be found at		The list of Internet-Draft Shadow Directories may be found at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document specifies how to use ECDSA (Elliptic Curve Digital		This document specifies how to use ECDSA (Elliptic Curve Digital
	Signature Algorithm) with the XML-digital signature syntax.		Signature Algorithm) with XML Signatures [XMLDSIG]. The mechanism
	The mechanism specified provides integrity, message authentication,		specified provides integrity, message authentication, and/or signer
	and/or signer authentication services for data of any type, whether		authentication services for data of any type, whether located
	located within the XML that includes the signature or included by		within the XML that includes the signature or included by reference.
	reference.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 2		2 ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Specifying ECDSA within XMLDSIG . . . . . . . . . . . . . . 2		3 Specifying ECDSA within XMLDSIG . . . . . . . . . . . . . . . . 3
	3.1. Identifier. . . . . . . . . . . . . . . . . . . . . . . . . 2		3.1 Version, Namespaces and Identifiers . . . . . . . . . . . . 3
	3.2. Core Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1.1 XML Schema Preamble . . . . . . . . . . . . . . . . 3
	3.3. ECDSA Signatures. . . . . . . . . . . . . . . . . . . . . . 4		3.1.2 DTD Replacement . . . . . . . . . . . . . . . . . . 3
	3.4. ECDSA Key Values. . . . . . . . . . . . . . . . . . . . . . 4		3.2 XML Schema Preamble and DTD Replacement . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . 4		3.2.1 XML Schema Preamble . . . . . . . . . . . . . . . . . 4
	5. Intellectual Property Rights . . . . . . . . . . . . . . . . 5		3.2.2 DTD Replacement . . . . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3 ECDSA Signatures . . . . . . . . . . . . . . . . . . . . . 4
	7. Authors' address . . . . . . . . . . . . . . . . . . . . . . 6		3.4 ECDSA Key Values . . . . . . . . . . . . . . . . . . . . . 4
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		3.4.1 Key Value Root Element . . . . . . . . . . . . . . . 5
	9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7		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 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 11
			6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			7 Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . 13
			8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
			9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13
			Appendix A: Aggregate XML Schema . . . . . . . . . . . . . . . . . 14
			Appendix B: Aggregate DTD . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document specifies how to use ECDSA (Elliptic Curve Digital		This document specifies how to use the Elliptic Curve Digital Signature
	Signature Algorithm) with the XML signature syntax.		Algorithm (ECDSA) with XML signatures as specified in [XMLDSIG]. Therein
	The XML Digital Signature syntax, or XMLDSIG is specified in		only two digital signature methods are defined: RSA signatures and DSA
	[RFC2807, XMLDSIG]. Currently there are only two digital signature		(DSS) signatures. This document introduces ECDSA signatures as an
	methods defined for use within XMLDSIG: RSA signatures and DSA (DSS)		additional method.
	signatures. This document introduces ECDSA signatures as a third
	method.
	This specification uses both XML Schemas [XML-schema] and DTDs [XML].		This document uses both XML Schemas [XML-schema] (normative) and DTDs
			[XML] (informational) for specifying the corresponding XML structures.
	2. ECDSA		2. ECDSA
	The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic		The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic
	curve analogue of the DSA (also called DSS) signature method		curve analogue of the DSA (DSS) signature method [FIPS186-2]. It is
	[FIPS186-2]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is		defined in the ANSI X9.62 standard [X9.62]. Other compatible
	defined in the ANSI X9.62 standard [ECDSA]; other compatible
	specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363],		specifications include FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363],
	and SEC1 [SEC1]. [PKIX2] describes the means to carry ECDSA keys in		and SEC1 [SEC1]. [RFC3279] describes the means to carry ECDSA keys in
	X.509 certificates. Recommended elliptic curve domain parameters for		X.509 certificates. Recommended elliptic curve domain parameters for
	use with ECDSA are given in [FIPS186-2], [SEC2], and [ECDSA].		use with ECDSA are given in [FIPS186-2], [SEC2], and [X9.62].
	Like DSA, ECDSA incorporates the use of a hash function; currently,		Like DSA, ECDSA incorporates the use of a hash function. Currently,the
	the only hash function defined for use with ECDSA is the SHA-1 message		only hash function defined for use with ECDSA is the SHA-1 message
	digest algorithm [FIPS-180-1].		digest algorithm [FIPS-180-1].
	ECDSA signatures are smaller than RSA signatures of similar		ECDSA signatures are smaller than RSA signatures of similar
	cryptographic strength. ECDSA public keys (and certificates) are smaller		cryptographic strength. ECDSA public keys (and certificates) are smaller
	than similar strength DSA keys, resulting in improved communications		than similar strength DSA keys, resulting in improved communications
	efficiency. Furthermore, on many platforms ECDSA operations can be		efficiency. Furthermore, on many platforms ECDSA operations can be
	computed faster than similar strength RSA or DSA operations (see [KEYS]		computed faster than similar strength RSA or DSA operations (see [KEYS]
	for a security analysis of key sizes across public key algorithms).		for a security analysis of key sizes across public key algorithms).
	These advantages of signature size, bandwidth, and computational		These advantages of signature size, bandwidth, and computational
	efficiency may make ECDSA an attractive choice for XMLDSIG		efficiency may make ECDSA an attractive choice for XMLDSIG
	implementations.		implementations.
	3. Specifying ECDSA within XMLDSIG		3. Specifying ECDSA within XMLDSIG
	This section specifies the details of how to use ECDSA with the		This section specifies the details of how to use ECDSA with XML
	XML-signature syntax. It relies heavily on the syntax and namespace		Signature Syntax and Processing [XMLDSIG]. It relies heavily on the
	defined in [XMLDSIG].		syntax and namespace defined therein.
	3.1 Identifier		3.1 Version, Namespaces and Identifiers
	The XML namespace [XML-ns] URI that MUST be used by implementations		No provision is made for an explicit version number in this syntax. If
	of this (dated) specification is:		a future version is needed, it will use a different namespace.
	xmlns="http://www.certicom.com/2000/11/xmlecdsig#"
	The identifier for the ECDSA signature algorithm is:
	http://www.certicom.com/2000/11/xmlecdsig#ecdsa-sha1
	3.2 Core Syntax		The XML namespace [XML-ns] URI that MUST be used by implementations of
			this (dated) specification is:
			http://www.buergerkarte.at/namespaces/ecdsa/200206030#
	The syntax is defined via DTDs and [XML-Schema] with the following XML		Elements in the namespace of the [XMLDSIG] specification are marked as
	preamble, declaration, internal entity, and simpleType:		such by using the namespace prefix "dsig" in the remaining sections of
	Schema Definition:		this document.
	<?xml version='1.0'?>		The identifier for the ECDSA signature algorithm is:
	<!DOCTYPE schema		http://www.buergerkarte.at/namespaces/ecdsa/200206030#ecdsa-sha1
	PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
	"http://www.w3.org/2000/10/XMLSchema.dtd"
	[
	<!ATTLIST schema
	xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
	<!ATTLIST schema
	xmlns:ecds CDATA #FIXED
	"http://www.certicom.com/2000/11/xmlecdsig#">
	<!ENTITY ecdsig 'http://www.certicom.com/2000/11/xmlecdsig#'>
	<!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'>
	]>
	<schema xmlns="http://www.w3.org/2000/10/XMLSchema"		3.2 XML Schema Preamble and DTD Replacement
	xmlns:ds="&dsig;"
	xmlns:ecds='&ecdsig;'
	targetNamespace="&ecdsig;"
	version="0.1"
	elementFormDefault="qualified">
	<!-- In order to include ECDSA in XML-signature syntax, the		3.2.1 XML Schema Preamble
	following definition of the KeyValue schema SHOULD
	replace the one in [XMLDSIG]-->
	<element name="KeyValue">		The subsequent preamble is to be used with the XML Schema definitions
	<complexType mixed="true">		given in the remaining sections of this document.
	<choice>
	<any namespace="##other" processContents="lax" minOccurs="0"
	maxOccurs="unbounded"/>
	<element ref="ds:DSAKeyValue"/>
	<element ref="ds:RSAKeyValue"/>
	<element ref="ecds:ECDSAKeyValue"/>
	</choice>
	</complexType>
	</element>
	DTD:		<?xml version="1.0" encoding="UTF-8"?>
			<xs:schema
			targetNamespace="http://www.buergerkarte.at/namespaces/
			ecdsa/200206030#"
			xmlns:ecdsa="http://www.buergerkarte.at/namespaces/ecdsa/200206030#"
			xmlns:xs="http://www.w3.org/2001/XMLSchema"
			elementFormDefault="qualified" attributeFormDefault="unqualified"
			version="0.2">
	<!-- In order to include ECDSA in XML-signature syntax, the		3.2.2 DTD Replacement
	following definition of the entity Key.ANY SHOULD
	replace the one in [XMLDSIG]-->
	<!ENTITY % Key.ANY '(#PCDATA|KeyName|KeyValue|RetrievalMethod|		In order to include ECDSA in XML-signature syntax, the following
	X509Data|PGPData|MgmtData|DSAKeyValue|RSAKeyValue|		definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]:
	ECDSAKeyValue)*'>
			<!ENTITY % KeyValue.ANY '| ecdsa:ECDSAKeyValue'>
	3.3 ECDSA Signatures		3.3 ECDSA Signatures
	The input to the ECDSA algorithm is the encoding of the SignedInfo		The input to the ECDSA algorithm is the canonicalized represenation of
	element as specified in Section 3 of [XMLDSIG]. The output of the		the dsig:SignedInfo element as specified in Section 3 of [XMLDSIG].
	ECDSA algorithm consists of a pair of integers usually referred by
	the pair (r, s). The signature value consists of the base64 encoding		The output of the ECDSA algorithm consists of a pair of integers usually
	of the concatenation of two octet-streams that respectively result		referred by the pair (r, s). The signature value (text value of element
	from the octet-encoding of the values r and s. r and s are each		dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the
	converted into octet strings of length [log_2 n/8], where n is the order		base64 encoding of the concatenation of two octet-streams that
	of the elliptic curve base point, using the conversion routine specified		respectively result from the octet-encoding of the values r and s. This
	in Section 4.3.1 of ANSI X9.62 [ECDSA].		concatenation is described in section E3.1 of [IEEE1363].
	3.4 ECDSA Key Values		3.4 ECDSA Key Values
	The syntax used for ECDSA key values closely follows the ASN.1 syntax		The syntax used for ECDSA key values closely follows the ASN.1 syntax
	defined in ANSI X9.62 [ECDSA].		defined in ANSI X9.62 [X9.62].
	ECDSA key values consist of two elements: ECDSAPublickey and		3.4.1 Key Value Root Element
	ECCParameters. ECDSAPublicKey contains the ECDSA public key which
	is a point on the elliptic curve and is encoded as a base64 value of
	its octet-stream representation converted as specified in
	Section 4.3.1 of ANSI X9.62 [ECDSA]. The element ECCParameters
	specifies the associated elliptic curve domain parameters which
	are represented by the nicknames given to them in [SEC2].
	Schema:		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.
	<element name='ECDSAKeyValue'>		The element consists of an optional subelement DomainParameters and the
	<complexType content='elementOnly'>		mandatory subelement PublicKey. If Domainparameters is missing in an
	<sequence minOccurs='1' maxOccurs='1'>		instance, this means that the application knows about them from other
	<element name='ECDSAPublicKey' type='ds:CryptoBinary'		means (implicitly).
	minOccurs='1' maxOccurs='1'/>
	<element name='ECCParameters' type='string'
	minOccurs='1' maxOccurs='1'/>
	</sequence>
	</complexType>
	</element>
	DTD:		Schema Definition:
	<!ELEMENT ECDSAKeyValue (ECDSAPublicKey, ECCParameters) >		<xs:element name="ECDSAKeyValue" type="ecdsa:ECDSAKeyValueType"/>
	<!ELEMENT ECDSAPublicKey (#PCDATA) >
	<!ELEMENT ECCParameters (#PCDATA) >		<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
			ressource 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>
			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 an characteristic
			two field parameters.
			The XML Schema type PrimeFieldParamsType is derived from FieldParamsType
			and is used for for encoding prime field parameters. The type contains
			as its single subelement P, the order of the prime field.
			The XML Schema type CharTwoFieldParamsType is derived from
			FieldParamsType as well 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 base fields 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.
			The XML Schema type TnBFieldParamsType is derived from
			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
			CharTwoFieldParamsType as well 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.
			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="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))>
			<!ELEMENT P (#PCDATA)>
			<!ELEMENT M (#PCDATA)>
			<!ELEMENT K (#PCDATA)>
			<!ELEMENT K1 (#PCDATA)>
			<!ELEMENT K2 (#PCDATA)>
			<!ELEMENT K3 (#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, while the optional element Seed contains the value used to derive
			the coefficients of a randomly generated elliptic curve, according to
			the algorithm specified in annex A3.3 of [X9.62].
			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)>
			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 curveÆs 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].
			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"/>
			<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>
	4. Security Considerations		4. Security Considerations
	Implementers should ensure that appropriate security measures are in		Implementers should ensure that appropriate security measures are in
	place when they deploy ECDSA within XMLDSIG. In particular, the security		place when they deploy ECDSA within XMLDSIG. In particular, the security
	of ECDSA requires the careful selection of both key sizes and elliptic		of ECDSA requires the careful selection of both key sizes and elliptic
	curve domain parameters. Selection guidelines for these parameters and		curve domain parameters. Selection guidelines for these parameters and
	some specific recommended curves that are considered safe are provided		some specific recommended curves that are considered safe are provided
	in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion,		in [X9.62], [NIST-ECC], and [SEC2]. For further security discussion,
	see [XMLDSIG].		see [XMLDSIG].
	skipping to change at page 5, line 28 ¶		skipping to change at page 11, line 46 ¶
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of		claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
	proprietary rights by implementers or users of this specification can		proprietary rights by implementers or users of this specification can
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	6. References		6. References
	[ECDSA] American National Standards Institute. ANSI X9.62-1998,		[FIPS-180-1] Federal Information Processing Standards Publication
	"Public Key Cryptography for the Financial Services		(FIPS PUB) 180-1, Secure Hash Standard, April 1995.
	Industry: The Elliptic Curve Digital Signature
	Algorithm". January, 1999.
	[FIPS-180-1] Federal Information Processing Standards Publication
	(FIPS PUB) 180-1, "Secure Hash Standard", April 17,
	1995.
	[FIPS-186-2] Federal Information Processing Standards Publication		[FIPS-186-2] Federal Information Processing Standards Publication
	(FIPS PUB) 186-2, "Digital Signature Standard",		(FIPS PUB) 186-2, Digital Signature Standard. January
	January, 2000.		2000.
	[IEEE1363] Institute for Electrical and Electronics Engineers (IEEE)		[IEEE1363] Institute for Electrical and Electronics Engineers (IEEE)
	Standard 1363-2000, "Standard Specifications for Public Key		Standard 1363-2000, Standard Specifications for Public Key
	Cryptography", 2000.		Cryptography. January 2000.
	[KEYS] Lenstra, A.K. and Verheul, E.R., "Selecting Cryptographic		[KEYS] Lenstra, A.K. and Verheul, E.R., Selecting Cryptographic Key
	Key Sizes", October 1999. Presented at Public Key		Sizes. October 1999. Presented at Public Key Cryptography
	Cryptography Conference, Melbourne, Australia, January,		Conference, Melbourne, Australia, January 2000.
	2000.
	http://www.cryptosavvy.com/		http://www.cryptosavvy.com/
	[PKIX2] Bassham, L., Housley, R., and Polk, W., "Internet X.509		[RFC3061] Mealling, M., RFC 3061, A URN Namespace of Object
	Public Key Infrastructure Representation of Public Keys		Identifiers. IETF Informational RFC, February 2001.
	and Digital Signatures in Internet X.509 Public Key		http://www.ietf.org/rfc/rfc3061.txt
	Infrastructure Certificates",
	draft-ietf-pkix-ipki-pkalgs-00.txt. July, 2000.
	[RFC2807] RFC 2807. XML Signature Requirements. J. Reagle, April 2000.		[RFC3279] Bassham, L., Housley, R., and Polk, W., RFC 3279, Algorithms
	http://www.w3.org/TR/xmldsig-requirements		and Identifiers for the Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile. IETF Proposed Standard, April 2002.
			http://www.ietf.org/rfc/rfc3279.txt
	[SEC1] Standards for Efficient Cryptography Group, "SEC 1:		[SEC1] Standards for Efficient Cryptography Group, SEC 1: Elliptic
	Elliptic Curve Cryptography", Version 1.0, September,		Curve Cryptography, Version 1.0, September 2000.
	2000. http://www.secg.org		http://www.secg.org
	[SEC2] Standards for Efficient Cryptography Group, "SEC 2:		[SEC2] Standards for Efficient Cryptography Group, SEC 2: Recommended
	Recommended Elliptic Curve Domain Parameters",		Elliptic Curve Domain Parameters, Version 1.0, September 2000.
	Version 1.0, September, 2000. http://www.secg.org		http://www.secg.org
	[XML] Extensible Markup Language (XML) 1.0 Recommendation.		[X9.62] American National Standards Institute. ANSI X9.62-1998,
	T. Bray, J. Paoli, C. M. Sperberg-McQueen. February, 1998.		Public Key Cryptography for the Financial Services Industry:
	http://www.w3.org/TR/1998/REC-xml-19980210		The Elliptic Curve Digital Signature Algorithm. January 1999.
	[XMLDSIG] XML-Signature Syntax and Processing.		[XML] Bray, T., Maler, E., Paoli, J. , and Sperberg-McQueen, C. M.,
	D. Eastlake, J. Reagle, D. Solo. July, 2000.		Extensible Markup Language (XML) 1.0 (Second Edition), W3C
	Work in progess.		Recommendation, October 2000.
	http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/		http://www.w3.org/TR/2000/REC-xml-20001006
	[XML-ns] Namespaces in XML Recommendation.		[XMLDSIG] Eastlake, D., Reagle, J., and Solo, D., XML-Signature
	T. Bray, D. Hollander, A. Layman. Janaury 1999.		Syntax and Processing. W3C Recommendation, February 2002.
	http://www.w3.org/TR/1999/REC-xml-names-19990114		http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
	[XML-schema] XML Schema Part 1: Structures Working Draft. D. Beech, M.		[XML-ns] Bray, T., Hollander, D., and Layman, A., Namespaces in XML,
	Maloney, N. Mendelshohn. April 2000.		W3C Recommendation, January 1999.
	http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/		http://www.w3.org/TR/1999/REC-xml-names-19990114/
	XML Schema Part 2: Datatypes Working Draft. P. Biron, A.
	Malhotra. April 2000.
	http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/
	7. Authors' Address		[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/
			7. Authors' Addresses
	Simon Blake-Wilson		Simon Blake-Wilson
	Yongge Wang		BCI
	Certicom Corp.		96 Spadina Ave, Unit 606
	5520 Explorer Dr.		Toronto, ON, M5V 2J6, Canada
	Mississauga, ON, L4W 5L1		e-mail: sblakewilson@bcisse.com
	e-mail: {sblakewilson, ywang}@certicom.com		Gregor Karlinger
			Chief Information Office Austria
			Parkring 10/I/5
			1010 Wien, Austria
			e-mail: gregor.karlinger@cio.gv.at
			Yongge Wang
			University of North Carolina at Charlotte
			9201 University City Blvd
			Charlotte, NC 28223, USA
			e-mail: ywang@uncc.edu
	8. Acknowledgements		8. Acknowledgements
	The authors would like to acknowledge the many helpful comments of		The authors would like to acknowledge the many helpful comments of
	Donald Eastlake, Tom Gindin, Cris Hawk, Joseph M. Reagle Jr., and		Wolfgang Bauer, Donald Eastlake, Tom Gindin, Chris Hawk, Joseph M.
	Francois Rousseau.		Reagle Jr., and Francois Rousseau.
	9. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Copyright (C) The Internet Society (1999). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain		others, and derivative works that comment on or otherwise explain
	it or assist in its implementation may be prepared, copied,		it or assist in its implementation may be prepared, copied,
	published and distributed, in whole or in part, without restriction		published and distributed, in whole or in part, without restriction
	of any kind, provided that the above copyright notice and this		of any kind, provided that the above copyright notice and this
	skipping to change at line 336 ¶		skipping to change at page 14, line 17 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Appendix A: Aggregate XML Schema
			<?xml version="1.0" encoding="UTF-8"?>
			<xs:schema targetNamespace="http://www.buergerkarte.at/namespaces/
			ecdsa/200206030#"
			xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xs="http://www.w3.org/2001/XMLSchema"
			xmlns:ecdsa="http://www.buergerkarte.at/namespaces/
			ecdsa/200206030#"
			elementFormDefault="qualified"
			attributeFormDefault="unqualified" version="0.3">
			<!--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>
			<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="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"/>
			<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:schema>
			Appendix A: 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))>
			<!ELEMENT P (#PCDATA)>
			<!ELEMENT M (#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)>
End of changes. 46 change blocks.
	177 lines changed or deleted		420 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/