Re: W3C Encryption Support for DES, RC2, and RC4 Symmetric Encry ptio n Algorithms

There are certain extratechnical reasons why ciphers such as Rijndael/AES
and triple-DES cannot be used. These may be legal reasons, export reasons,
hardware reasons, commercial reasons, etc. The fact that AES is better,
faster and MUST be implemented by conformant encryptors does not impact
this reality.

By refusing to provide a standard URI for these algorithms - along with
explicit text explaining that the algorithms are unsafe - we prevent
applications that are bound by these extratechnical limitations from
interoperating.

While I am not convinced that RC2 should be specified, I do see a valid
reason to define an informational URI for DES, as we do for RC4. I
would not want it in the core spec; however someone must, eventually,
define such a URI. Our ancillary security URI document would seem the
most appropriate place.

I do not support or recommend the use of these algorithms; nor would I
enable them in a normal security application. However, I do recognize
that there are abnormal occasions where there is no alternative and
we would serve the community better by supporting this reality and
providing appropriate cautionary text. You would seem well opined to
provide such text.

Merlin

r/ashwood@msn.com/2002.06.20/16:14:36
>
>----- Original Message -----
>From: "Tom Gindin" <tgindin@us.ibm.com>
>
>>       The major reason IMHO why anyone would want to use some of these
>> algorithms which are 64 bits or less would be that no stronger algorithm
>is
>> available in both the encryptor's environment and the decryptor's.
>
>Since 128-bit Rijndael/AES is required, that situation can never occur,
>there will always be a 128-bit algorithm available.
>
>> The
>> legacy that matters in this case consists of legacy crypto libraries since
>> obviously there's no legacy of XML-encrypted documents.
>
>With Rijndael as a requirement, the presence of a legacy crypto library is
>unlikely. With the additional observation that libraries like OpenSSL and
>Crypto++ are available free it is even less likely that legacy crypto
>libraries will be used.
>
>>DES is also faster
>> than 3DES, of course, but that's not a very strong reason.
>
>And Rijndael is faster than either, more secure, and one of the required
>algorithms.
>
>>       My own point had to do with PBE because of its key exchange and
>> storage characteristics.  I don't think we should try to add every PBE
>> variant in PKCS#5 and PKCS#12, let alone all others which have ever been
>> defined.
>
>PBEs might be useful, but I think they should focus on the algorithms that
>are already significant options, like Rijndael/AES, 3DES, etc. This would
>reduce the code necessary for an implementation, reduce the executable size,
>and shrink the specification, and won't compromise security or the speed.
>                    Joe
>

Received on Friday, 21 June 2002 01:23:35 UTC