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

Re: proposed editor's note on mandatory to implement algorithms (ACTION-214)

From: Magnus Nyström <magnus@rsa.com>
Date: Wed, 18 Feb 2009 14:10:43 +0100 (W. Europe Standard Time)
To: Frederick Hirsch <frederick.hirsch@nokia.com>
cc: XMLSec WG Public List <public-xmlsec@w3.org>
Message-ID: <Pine.WNT.4.64.0902181410110.5768@W-JNISBETTEST-1.tablus.com>
FWIW I'd support these changes.

-- Magnus

On Tue, 17 Feb 2009, Frederick Hirsch wrote:

> I suggest the following change to your proposed editors note:
>
> (a) Change "Positions of Working Group members include:" to
> "Positions of some Working Group members against the currently expressed 
> mandatory algorithms include:"
>
> (b) For #2 suggest changing
> "both for hash and public-key algorithms." to "both for hash and public-key 
> algorithms, in the event one is proven insecure, to enable a quick change to 
> an alternative."
>
> (c) in #2 Remove ", which is, e.g., not the case for RSA."
>
> (d) change #3 to:
>
> 3. There should be recommended algorithms, but no mandatory to
> implement algorithms.  The rationale is that this gives greater flexibility 
> to deployments. (Other WG members argued against this since it could harm 
> interoperability not having mandatory algorithms.)
>
> regards, Frederick
> Frederick Hirsch
> Nokia
>
> On Feb 17, 2009, at 6:20 PM, ext Thomas Roessler wrote:
>
>> Here's a proposal for an editor's note that can be added to the
>> Encryption 1.1 and Signature 1.1 WDs (in Signature this should go into
>> the beginning of section 6; haven't looked where it best fits into
>> Encryption), with an additional pointer in the status of the document:
>> 
>>> There is currently no consensus on mandatory to implement
>>> algorithms; the current draft text represents one possible outcome.
>>> Positions of Working Group members include:
>> 
>> For Signature:
>> 
>>> 1. RSA and DSA are acceptable as a mandatory to implement signature
>>> algorithms.  Given limited support in parts of the industry,
>>> elliptic curve DSA is not acceptable as a mandatory to implement
>>> algorithm, and might lead to lack of implementation of this version
>>> of the specification.
>> 
>> For Encryption:
>> 
>>> 1. Given limited support in parts of the industry, Elliptic Curve
>>> Diffie-Hellman Key Agreement is not acceptable as a mandatory to
>>> implement algorithm in this specification, and might lead to lack of
>>> implementation of this version of the specification.
>> 
>> Then, for both specs:
>> 
>>> 2. Going forward, this specification needs to have credible
>>> algorithm agility, both for hash and public-key algorithms.
>>> Therefore, there should be two mandatory to implement public-key
>>> algorithms from different families.  At this time, elliptic curve
>>> based algorithms are the only credible contenders.  They have the
>>> additional benefit of providing a reasonable balance between key
>>> sizes and security level, which is, e.g., not the case for RSA.
>> 
>> Signature only:
>> 
>>> As profiles built on top of XML Signature that currently rely on DSA-
>>> SHA1 or RSA-SHA1 as the only supported signature algorithm will need
>>> to be updated in the future, the Signature core specification should
>>> outline a clear way forward in terms of choice of algorithms.  This
>>> choice should be Elliptic Curve DSA.
>> 
>> Both:
>> 
>>> 3. There should be recommended algorithms, but no mandatory to
>>> implement algorithms.  On certain constrained devices, only a single
>>> algorithm might be implemented at a given time, but there may be
>>> updatte mechanisms in place that enable algorithm agility in
>>> deployments.
>> 
>>> The Working Group welcomes further community input and comment on
>>> this issue.
>> 
>> 
>> Rob, Brian, Chris, Ken -- please let me know whether this describes
>> your positions in reasonable accuracy, and feel free to suggest finer
>> word-smithing.
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
Received on Wednesday, 18 February 2009 13:11:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:57 GMT