W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2000

Re: Algorithm Selections

From: Aram Perez <aperez@wavesys.com>
Date: Mon, 27 Nov 2000 14:11:18 -0800
To: "Joseph M. Reagle Jr." <reagle@w3.org>
cc: jimsch@nwlink.com, "'Xml-Encryption \(E-mail\)" <xml-encryption@w3.org>
Message-ID: <852569A4.0079B50E.00@mail2.wavesys.com>

11/27/2000 05:11 PM
Hi Joseph,

According to http://csrc.nist.gov/encryption/aes/round2/aesfact.html, Q&A 8,
NIST expects AES to be a formalized as a standard in the April-June, 2001
timeframe. I suspect I've raised a mute point.


"Joseph M. Reagle Jr." <reagle@w3.org> on 11/27/2000 01:14:44 PM

cc:   jimsch@nwlink.com, "'Xml-Encryption \(E-mail\)" <xml-encryption@w3.org>

Subject:  Re: Algorithm Selections

Hi Aram, I'm going through emails and tweaking the requirements document,
two quick points:

At 10:31 11/21/2000 -0800, Aram Perez wrote:
>other key lengths and TripleDES are MAY. **#** My concern is whether we
>to publish our specification before AES becomes an official standard. Is
>anyway of specifying something like "TripleDES is a MUST until AES is
>When AES is official, then AES is a MUST and TripleDES is a MAY."

 From a specification conformance point of view, this wouldn't make much
sense: at some undefined point, something is published and the meaning of
our conformance changes. At W3C, a Recommendation has a specific static
meaning via references to other dated/static specifications. If we find that
AES is being advanced too slowly, we need to wait for it, or move on without

>Recommondation.:  Make the AES keywrap from the NSA be the manditory when it
>appears. **#** I would also add a recommendation that "weaker" keys not wrap
>"stronger" keys, i.e., don't wrap a TripleDES key with a 64 bit RC2 key.

I'll leave this to the specification or an implementation recommendation.

Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Monday, 27 November 2000 17:05:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:59 UTC