"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
document.
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 SMimeCapabilities 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?
[pause]
Oh, sorry, that was ietf-tls which looked at it. The conclusion there
was:
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 there's no
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 cavalier :-),
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).
Peter.