W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2009

Requirements document; proposed updates

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Fri, 23 Jan 2009 11:44:04 -0500
Message-Id: <FFC6C4F3-7117-4039-BFEF-400AAF4CFC1C@nokia.com>
To: XMLSec WG Public List <public-xmlsec@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>

Proposed updates to requirements document [1], (in addition to agreed  
at F2F decision to move section, 4.4 canonicalization requirements,  
[2] to transform document [3]):

(1) Remove empty section 1, Scope, as discussed at F2F

(2) Remove empty section 4.3, "XML Signature", as discussed at F2F

(3) add new section (currently 4.7) after Transforms section as follows:

4.7 Algorithm security and interoperability

4.7.1 Fundamentals

XML Signature specifies algorithm identifiers and implementation  
requirements for algorithms related to various aspects of signature  
processing, including digest and signature algorithms. The algorithms  
listed in XML Signature, Second Edition date from the original XML  
Signature Recommendation, published in 2002. Since that time there  
have been new algorithms introduced to address security risks  
associated with earlier algorithms (e.g. SHA-256 versus SHA-1),  
changes in patent status related to algorithms (e.g. RSA signing no  
longer has licensing requirements), and additional algorithms  
introduced to meet additional requirements (Suite B algorithms  

In order to meet the principle of "Secure" and "Pragmatic", new  
algorithm requirements should be met.

4.7.2 Requirements Address SHA security concerns, recognize RSA de-facto use.

In order to address concerns related to potential risks associated  
with SHA-1, the following algorithm requirements that update the SHA  
algorithm should be met in XML Signature:

* Digest: SHA256 be required, SHA384 and SHA512 optional.
* Mac: HMAC-SHA256 recommended, HMAC-SHA384 and HMAC-SHA512 optional
* Signature: RSAwithSHA256 required, and RSAwithSHA384, RSAwithSHA512  
optional Revise guidance for DSAwithSHA1

  In order to discourage the use of DSAwithSHA1 but to continue to  
enable interoperability, the following algorithm changes are  

* Signature, continue to require DSAwithSHA1 for signature  
verification, but change DSAwithSHA1 to optional (from required) for  
signature generation. Add Suite B algorithm support

In order to enable use of XML Signature technology in interoperable US  
government applications that require Suite B, elliptic curve  
algorithms are to be added to XML Signature as follows:

* Signature: Require ECDSAwithSHA256. ECDSAwithSHA1, ECDSAwithSHA384,  
ECDSAwithSHA512 optional

* Define ECKeyValue element to enable interoperable exchange of EC  
public key values and provide
  profile guidance for use of RFC 4050, though indicate preference for  
mechanism defined in XML Signature.

Details of the last requirement relate to the ECKeyValue design.

4.7.3 ECKeyValue design

RFC 4050 is an informational RFC that defines a method of
representing ECDSA public keys and ECC curve parameters for use with  
XML Signature.

The RFC 4050 definition of an ECDSAKeyValue is larger than necessary

        An ECDSAKeyValue is defined by the type ECPointType, which has  
        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  
        from the Xml schema instance namespace.


          <ECDSAKeyValue xmlns="http://www.w3.org/2001/04/xmldsig- 
                 <NamedCurve URN="urn:oid:1.2.840.10045.3.1.7"/>
              <PublicKey xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance 

        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:element name="FieldParams"  
                 <xs:element name="CurveParams"  
                 <xs:element name="BasePointParams"
          <xs:complexType name="CurveParamsType">
                 <xs:element name="A" type="ecdsa:FieldElemType"/>
                 <xs:element name="B" type="ecdsa:FieldElemType"/>
                 <xs:element name="Seed" type="xs:hexBinary"  
          <xs:complexType name="BasePointParamsType">
                 <xs:element name="BasePoint" type="ecdsa:ECPointType"/>
                 <xs:element name="Order" type="xs:positiveInteger"/>
                 <xs:element name="Cofactor" type="xs:positiveInteger"

        Notice that the field parameters are already included in the  
        element. The use of the FieldParamsType in the ECPointType  
        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  
        version, section 4.3.6 in the 1998 version). The conversion  
functions in
        X9.62 are not ASN.1 specific and it appears 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  
        extension fields) as xs:nonNegativeInteger which derives from  
        xs:decimal primitive type. However, XSD requires  
implementations to support
        only a minimum of 18 digits.


        My example above required 77 and 78 digits for X and Y  
        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  
        Y is defined as:

        <!ELEMENT Y EMPTY>

        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  
        which is basically the example above.

Add reference

[SUITEB]  “Fact Sheet NSA Suite B Cryptography”,


regards, Frederick

Frederick Hirsch

[1] http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html

[2] http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html#c14n-reqs

[3] http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
Received on Friday, 23 January 2009 16:46:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:10 UTC