There is one large difference between TLS and CMS. The TLS protocol has
already been modified to deal with the attacks on PKCS#1 v1.5, CMS has
not been modified to deal with these attacks. Therefore I do not
necessarily think that the TLS conclusion on this is sufficient.
From: Peter Gutmann [mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Wednesday, July 17, 2002 3:21 PM
To: ietf-smime(_at_)imc(_dot_)org; jimsch(_at_)exmsft(_dot_)com
Subject: Re: AES and PKCS #1 v1.5 Issue
"Jim Schaad" <jimsch(_at_)nwlink(_dot_)com> writes:
The face-to-face meeting was presented with the following choices:
1. Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
2. Remove the ban, but allow the author to present a diatribe on why
it's a bad idea.
3. Remove the ban entirely and force an update to
allow for products to advise that the combination is not acceptable.
Didn't we go through all this (endlessly) ages ago, and more or less
resolve to let people use PKCS #1 if they wanted to?
Oh, sorry, that was ietf-tls which looked at it. The conclusion there
If people are interested in seeing OAEP adopted it won't
need to use the
momentum AES has created. If people aren't interested then
it won't get
adopted, but that's the way it should be.
ietf-tls also looked into simple-RSA, the general opinion was that if
any change is made, simple-RSA would be a better choice since
OAEP deployed base to be compatible with.
Given that every S/MIME implementation around already does AES with
PKCS #1 (is there anyone who hasn't added AES support yet?), mandating
OAEP is just going to be another X9.42 - everyone pretends to do it
but does PKCS #1 instead. This is going to sound somewhat
but as far as I'm concerned the RFC can really say whatever it wants.
Option 1 will be ignored entirely, 2 will be read but ignored, and 3
would be the pragmatic solution (or do 2+3, which seems the obvious
one - tell people it's a bad thing, and provide an SMimeCap to allow
OAEP if people want it).