- From: Marcos Caceres <w3c@marcosc.com>
- Date: Thu, 15 Dec 2011 18:07:25 +0000
- To: Brian LaMacchia <bal@microsoft.com>
- Cc: Thomas Roessler <tlr@w3.org>, Philippe Le Hegaret <plh@w3.org>, 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>
On Thursday, December 15, 2011 at 4:51 PM, Brian LaMacchia wrote: > 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. The PAG has some good recommendations to help the situation (e.g., contributing prior art). If the patent can be showed to be invalid (or the party that disclosed is willing to work with the WG and the W3C around the patent), then the PAG can close quickly. Otherwise, I don't see much choice but to remove it ECC. There is no magic bullet. > 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). In reality, no widget uses ECC, and no widget implementer implements ECC that I know of (call it a "willful" conformance violation - and no one will lose any sleep over not implementing a "mandatory-to-implement signature algorithm" that no one now dares to use). The spec can't force people to implement something patent encumbered for the sake of compliance, and recommendations can be ignored… as the are, after all, "recommendations" and not government standards that can be enforced by law (hence, there is no such thing as a "mandatory-to-implement signature algorithm": there is just goodwill to conform where it's not a (patented) problem to do so). Furthermore, specs should balance the needs of the market. Would it really be that bad to take our ECC and publish a companion spec with just ECC straight away? Should one aspect block the progression of the whole spec? > 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. Separate thread. > > 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. > Amen! :)
Received on Thursday, 15 December 2011 19:13:35 UTC