"Housley, Russ" <rhousley(_at_)rsasecurity(_dot_)com> writes:
SMIMECapabilities cannot solve this problem.
Suppose that I have two certificates, each with an RSA public key. I want to
use one of the public keys with PKCS #1 v1.5 and the other with OAEP. In the
current approach, both certificates have a key usage of keyEncipherment, and
both certificates have a SubjectPublicKeyInfo AlgorithmIdentifier of
rsaEncryption. Also, SMIMECapabilities indicates both PKCS #1 v1.5 and OAEP.
Therefore, a message originator has no idea which public key to use with PKCS
#1 v1.5 and vice versa.
Fair enough. However, I still can't see this flying... there's a Far Side
cartoon which shows two points of view of someone talking to a dog, the human
side is something like "This is my dog Fido, who's friendly with strangers,
doesn't chew the furniture, and doesn't get into fights with other dogs", and
the dog's side is "blah blah blah blah *Fido* blah blah blah blah blah blah
blah blah". Getting this change across to end users will be similar, the
techies side will be "There's some obscure problem with existing RSA keys which
is too technical to explain and probably won't affect anyone, but just to be
safe we're making a switch to something else. A slight downside is that
nothing will work any more with the new keys" and the masses will get "blah
blah blah blah blah blah *nothing will work any more with the new keys*". You
may as well have the certificates made out of asbestos using child labour for
all the user buy-in they're going to get.
I don't think this is a solveable problem. To kill PKCS #1, you need to make
sure the keys can only be used with OAEP. By making sure they're only usable
with OAEP, they won't work when users try and do anything with them. The
outcome is a foregone conclusion - it's X9.42 certs all over again.
I guess I've said my bit on this topic. I certainly won't object if people
want to create OAEP OIDs and mechanisms and whatnot, but I'll stick with PKCS
#1 v1.5.
Peter.