- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Mon, 26 Jan 2009 10:14:13 -0500
- To: "ext Edgar, Gerald" <gerald.edgar@boeing.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "XMLSec WG Public List" <public-xmlsec@w3.org>
- Message-Id: <678BF920-F261-4471-BC14-7DBD367B8015@nokia.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
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, and to enable long term
security
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
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
regards, Frederick
Frederick Hirsch
Nokia
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