Summary of problems with the definition of ECDSA public key in RFC 4050

Background: RFC 4050 is an informational RFC that defines a method of
representing ECDSA public keys and ECC curve parameters for use with XMLDSIG.
As part of the new alg work for XMLDSIG 1.1 I've been investigating whether
RFC 4050 is an appropriate starting point for our ECDSA support. In particular,
I've been looking at whether we can import the ECDSAKeyValue and ECPointType
elements into XMLDSIG easily.  Here is a summary of the problems.

The RFC 4050 definition of an ECDSAKeyValue is larger than necessary

       An ECDSAKeyValue is defined by the type ECPointType, which has subelements
       X and Y. X and Y are defined as FieldParamsType which is an abstract type.
       Separate derived types are defined for prime fields, trinomial base fields,
       pentanomial base fields, and odd characteristic extension fields.  In order
       to validate against the 4050 schema, one must include the type attribute
       from the Xml schema instance namespace.

       The example below was (mostly) generated using .NET 3.5 on Vista SP1,
       except that I had to manually add the xsi:type attribute in order to make
       it conform to the RFC 4050 schema.

         <ECDSAKeyValue xmlns="http://www.w3.org/2001/04/xmldsig-more#">
             <DomainParameters>
                <NamedCurve URN="urn:oid:1.2.840.10045.3.1.7"/>
             </DomainParameters>
             <PublicKey xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <X Value="58511060653801744393249179046482833320204931884267326155134056258624064349885"
                 xsi:type="PrimeFieldElemType"/>
                <Y Value="102403352136827775240910267217779508359028642524881540878079119895764161434936"
                 xsi:type="PrimeFieldElemType"/>
             </PublicKey>
         </ECDSAKeyValue>

       This is not a significant problem but it does make the public key larger
       than necessary.

ECPointType definition is inconsistent with ANSI X9.62 and RFC 3279

       ECPointType is reused in the definition of the ExplicitParamsType to
       describe the base point of a curve. ExplicitParamsType is defined as

         <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>

       Notice that the field parameters are already included in the FieldParams
       element. The use of the FieldParamsType in the ECPointType definition
       appears to be a mistake in 4050. If you look at the ASN.1 definition for
       ECC public keys in RFC 3279, ECPoint simply references the Point to Octet
       String conversion function in ANSI X9.62 (section A.5.6 in the 2005
       version, section 4.3.6 in the 1998 version). The conversion functions in
       X9.62 are not ASN.1 specific and I believe they would be implemented as
       part of any ECC crypto library. It appears that RFC 4050 tried to avoid
       using any of the conversion functions in X9.62 but somehow mixed up the
       definitions between a field type and a field element.

Limitation of the decimal type in XSD

       RFC 4050 defines X and Y (at least for prime and odd characteristic
       extension fields) as xs:nonNegativeInteger which derives from the
       xs:decimal primitive type. However, XSD requires implementations to support
       only a minimum of 18 digits.

           http://www.w3.org/TR/xmlschema-2/#decimal

       My example above required 77 and 78 digits for X and Y respectively.
       This means that there is no guarantee that an RFC 4050 compliant
       ECDSAKeyValue element will actually validate against the RFC 4050 schema.
       (It did not when I tried the example above with the XML editor in Visual
       Studio 2008, for example).

Collision between the RFC 4050 DTD and the XMLDSIG DTD

       I could not merge the RFC 4050 DTD into the XMLDSIG DTD. In ECDSAKeyValue,
       Y is defined as:

       <!ELEMENT Y EMPTY>
       <!ATTLIST Y Value CDATA #REQUIRED>

       However, DSAKeyValue defines Y as follows:

       <!ELEMENT Y (#PCDATA) >

       ECDSAKeyValue also contains identical definition for elements SEED and P
       as DSAKeyValue.

       I don't know if there is a way to scope the definition of Y under a
       specific element in DTD.


Proposed Solution

       Because of these issues, I believe XMLDSIG 1.1 should not attempt to reuse
       the RFC 4050 ECDSAPublicKey elements.  Instead, I proposed that XMLDSIG 1.1
       define a new ECPublicKey element in the ds namespace to address problems
       in the RFC 4050 schema and will be based on the ASN.1 definition in ANSI
       X9.62 and RFC 3279. Changing the name of the element to ECPublicKey means
       we can reuse it when we update Xml Encryption to support ECDH.

       To maximize interoperability with existing RFC 4050 implementations, I
       would like to put a note in 1.1 to recommend implementations to support a
       profile of RFC 4050. The profile will support only named prime curves
       which is basically the example above.

Kelvin