Subject: Re: RSA OAEP Public Key Identification

From: [email-masked] (Peter Gutmann)
Date: Fri, 2 Aug 2002 20:49:18 +1200 (NZST)

"Housley, Russ" <[email-masked]> writes:

>Here is my proposed solution: use a different algorithm identifier in the
>certificate.  I suggest that the id-RSAES-OAEP be used in the certificate
>subject public key info field to indicate that the public key should ONLY be
>used with RSA OAEP.

Hmm, I can see some problems with this.  From the technical point of view it's
probably the easiest way to do it, but I can see horrible deployment problems.
What you're doing is creating something which quacks like an RSA key but which
will fail to work with anything which normally uses RSA keys.  I think I'd
have quite some problems laying this out for developers, let alone end users -
all they'd see is an RSA key which doesn't work properly.

I'm also not sure that this is an algorithm issue.  An RSA key is an RSA key,
whether you use it for PKCS #1, 9796, X9.31, or OAEP.  We don't ship them with
OIDs saying they can't be used to wrap RC4/40 keys, or used on public internet
terminals, or fed to your parrot.

I'd prefer to delegate this to the application (via SMIMECapabilities) like
most other stuff of this nature.  Alternatively, create an extKeyUsage or
something, but creating a cert which (deliberately) doesn't work properly when
you try and use it really seems to be asking for trouble.

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 02 Aug 2002 09:34:42 -0400

Peter:

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.

The security considerations section is prudent; it recommends that just one 
content-encryption key scheme be used with a particular key pair.  The 
current approach does not give the message originator sufficient 
information to implement it.

Russ