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

Re: Requirements document; proposed updates

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Mon, 26 Jan 2009 10:14:13 -0500
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "XMLSec WG Public List" <public-xmlsec@w3.org>
Message-Id: <678BF920-F261-4471-BC14-7DBD367B8015@nokia.com>
To: "ext Edgar, Gerald" <gerald.edgar@boeing.com>
Updated proposal

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 [SUITEB]).

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,  and to enable long term  
for commercial companies elliptic curve algorithms are to be added to  
XML Signature.
As new hardware is developed and new algorithms to break cryto systems  
are found, the stronger algorithms offered by elliptic curve enable  
longer term security.

  The additional algorithm requirements are 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"/>

        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
        define a new ECPublicKey element in the ds namespace to address
        in the RFC 4050 schema and will be based on the ASN.1 definition
        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


[3] http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html

regards, Frederick

Frederick Hirsch

On Jan 23, 2009, at 11:54 AM, ext Edgar, Gerald wrote:

> The need for stronger encryption such as NSA's Suite B is not only  
> from
> government requirements, but it is also a need for long term security
> from commercial companies.  As new hardware is developed, and new
> algorithms to break cryto systems are found, the stronger algorithms
> enable a longer term security.
> Gerald Edgar, CISSP
> Enterprise Architecture & Information Security
> Cell: 425-503-3912
> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> Sent: Friday, January 23, 2009 8:44 AM
> To: XMLSec WG Public List
> Cc: Frederick Hirsch
> Subject: Requirements document; proposed updates
Received on Monday, 26 January 2009 15:15:25 UTC

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