W3C home > Mailing lists > Public > public-xmlsec@w3.org > December 2011

RE: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

From: Brian LaMacchia <bal@microsoft.com>
Date: Thu, 15 Dec 2011 16:51:48 +0000
To: Thomas Roessler <tlr@w3.org>, Philippe Le Hegaret <plh@w3.org>
CC: Arthur Barstow <art.barstow@nokia.com>, Frederick Hirsch <frederick.hirsch@nokia.com>, Marcos Caceres <marcosscaceres@gmail.com>, Doug Schepers <schepers@w3.org>, Rigo Wenning <rigo@w3.org>, public-webapps <public-webapps@w3.org>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>, Magnus Nystrom <mnystrom@microsoft.com>
Message-ID: <3D9A599D97FFC643A4B7A0710BEF4D9915D94ACC@TK5EX14MBXC263.redmond.corp.microsoft.com>
Hello all,

Sorry for coming to this thread late (I'm on vacation) but I want to comment on a number of points raised during this thread:

1) Concerning the suggestion to move ECDSA out of XMLDSIG 1.1, that suggestion is a non-starter for XMLDSIG.  One of the main motivations for XMLDSIG 1.1 is to update the spec to support Suite B cryptography, and that means ECDSA support has to be there.  Delaying ECC is not a viable option for XMLDSIG.

2) I do not understand the comments that Widget-DSig is independent of ECC.  As far as I can tell from reading the spec, while  Widget-Dsig makes certain recommendations about algorithms and key sizes legally Widget-DSig has to work with any XMLDSIG 1.1 mandatory-to-implement option.  That is, Widget-DSig does not *profile* XMLDSIG 1.1 but simply says "use XMLDSIG 1.1".  Since ECDSA-SHA256 is a mandatory-to-implement signature algorithm in XMLDSIG 1.1, every Widget-DSig implementation would have to support it (it would be violating the XMLDSIG 1.1 spec otherwise).

3) Widget-DSig's choice of RSA-4096 is particularly surprising given the increased size of the signature & verification cost relative to ECDSA-SHA256.  That's not going to be efficient to validate, especially not for smartphones and other low-power devices.

4) We (Microsoft, specifically Magnus and myself) are also distressed with the lack of resolution to the ECC PAG and once again we strongly encourage W3C staff to take a more active role in the PAG and lead it forward to its logical conclusion. 

Widget-DSig is not the only spec out there with a dependency on the upcoming XMLDSIG 1.1, but the fact that it is blocked too is all the more reason for W3C to expedite conclusion of the PAG. 


-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Thursday, December 15, 2011 6:44 AM
To: Philippe Le Hegaret
Cc: Thomas Roessler; Arthur Barstow; Frederick Hirsch; Marcos Caceres; Doug Schepers; Rigo Wenning; public-webapps; public-xmlsec@w3.org
Subject: Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

Works for me, too.
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)

On 2011-12-13, at 22:14 +0100, Philippe Le Hegaret wrote:

> On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote:
>> Hi All,
>> The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 
>> months now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this 
>> PAG has just started its unspecified length Fishing Expedition 
>> seeking some unspecified level of funds to pay for some type of 
>> analysis that will take some unknown amount of time to complete ...
>> Given this, and not wanting to block on the ECC PAG any longer, what 
>> are the options to move widgets-digsig to REC ASAP?
>> Some options:
>> 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this 
>> would require a new 3-week LC but the CR could be zero-length, 
>> presumably no re-testing would be required, and the only thing 
>> blocking PR->REC is the length of the new CfE that would be needed.
>> 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so
>> XMLSig1.1 is not affected by the PAG and XMLSig1.1 can then continue 
>> on the REC track.
>> 3. Others?
> An other one was for the Director to decide to move the document 
> forward anyway because W-DigSig doesn't depend on ECC.
> Thomas, any suggestion?
> Philippe
Received on Thursday, 15 December 2011 17:08:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:28 UTC