- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 20 Feb 2009 00:01:57 +0100
- To: Magnus Nyström <magnus@rsa.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Test in Signature is now: > <div class="note"> > <p> > There is currently no consensus on mandatory to implement > algorithms; the current draft text > represents one possible outcome. Positions of some Working > Group members against the > currently expressed set of mandatory to implement algorithms > include: > </p> > <ul> > <li>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.</li> > <li>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.)</li> > </ul> > <p> > The opposing position is that, going forward, this > specification needs to have credible > algorithm agility for both hash and public-key algorithms: > Should one set of algorithms prove > weak, this would enable a quick switch-over. 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. 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. > </p> > </div> Text in Encryption: > > <div class="note"> > <p> > There is currently no consensus on mandatory to implement > algorithms; the current draft text > represents one possible outcome. Positions of some Working > Group members against the > currently expressed set of mandatory to implement algorithms > include: > </p> > <ul> > <li>Given limited support in parts of the industry, Elliptic > Curve Diffie-Hellman Key > Agreement is not acceptable as a mandatory to implement > algorithm, and might lead to lack of > implementation of this version of the specification.</li> > <li>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.)</li> > </ul> > <p> > The opposing position is that, going forward, this > specification needs to have credible > algorithm agility for both hash and public-key algorithms: > Should one set of algorithms prove > weak, this would enable a quick switch-over. 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. > </p> > </div> -- Thomas Roessler, W3C <tlr@w3.org> On 18 Feb 2009, at 14:10, Magnus Nyström wrote: > 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 Thursday, 19 February 2009 23:02:09 UTC