RE: Requirements document; proposed updates

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


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

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

4.7.2.1 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

4.7.2.2 Revise guidance for DSAwithSHA1

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

* Signature, continue to require DSAwithSHA1 for signature verification,
but change DSAwithSHA1 to optional (from required) for signature
generation.

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

        example

          <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
=
"58511060653801744393249179046482833320204931884267326155134056258624064
349885
"
                  xsi:type="PrimeFieldElemType"/>
                 <Y
Value
=
"10240335213682777524091026721777950835902864252488154087807911989576416
1434936
"
                  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 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
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.


References:
Add reference

[SUITEB]  "Fact Sheet NSA Suite B Cryptography",
www.nsa.gov/ia/industry/crypto_suite_b.cfm.

---

regards, Frederick

Frederick Hirsch
Nokia


[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:55:25 UTC