Subject: Re: RSA OAEP Public Key Identification

From: [email-masked] (Peter Gutmann)
Date: Sat, 3 Aug 2002 20:08:34 +1200 (NZST)

"Housley, Russ" <[email-masked]> 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.

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 6 Aug 2002 16:15:46 -0400

I have two reasons for saying "not EKU".
 
1.  The PKIX Certificate and CRL profile (RFC 3280) has the following text
describing EKU:

If the extension is present, then the certificate MUST only be used for one
of the purposes indicated.  If multiple purposes are indicated the
application need not recognize all purposes indicated, as long as the
intended purpose is present.  

Thus, for example, if the certificate had both id-RSAES-OAEP and
id-kp-emailProtection, then the key could legally be used for protecting
email, without regard for whether or not OAEP or PKCS #1 v1.5 should be
used.  Now, S/MIME could make a requirement that when encrypting for a
recipient and using OAEP then the id-RSAES-OAEP OID must be present, but
then that requirement wouldn't be necessarily binding on all other
applications that may process that certificate.
 
2.  In my opinion EKU was meant to identify application-level purposes for
which the key may be used, not algorithm-level purposes.  Looking at the
purposes defined in RFC3280 confirms this (server auth., client auth., code
signing, email protection, time stamping, OCSP signing).  Algorithm usages
belong in the subjectPublicKeyInfo and placing them in EKU just
unnecessarily complicates things.

-----Original Message-----
From: Simon Blake-Wilson [mailto:[email-masked]]
Sent: Tuesday, August 06, 2002 9:31 AM
To: 'Robert Zuccherato'; 'Housley, Russ'; [email-masked]
Subject: RE: RSA OAEP Public Key Identification

Can one of you please expand on "Why not EKU?" (Since I included it in all
the ECC stuff, if there's a good reason why not, maybe we can change
things.) Naively it seems like EKU has a bunch of nice properties ... for
example you can use it to place the policy decision on the private key
holder or the public key holder with the criticality flag, you can
acknowledge that using keys with multiple algs happens and at least make you
the keys are only used with the OIDs listed, you have a reasonable migration
path by making the extension non-critical initially, etc. Is it just lack of
support for EKU in PKI products that makes introducing a new OID in
subjectPublicKeyInfo desirable?

Best regards. simon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Zuccherato
Sent: Friday, August 02, 2002 9:41 AM
To: 'Housley, Russ'; [email-masked]
Subject: RE: RSA OAEP Public Key Identification

Russ; 

I think that including the id-RSAES-OAEP be used in the certificate subject
public key info field is the right way to go.  The only other option that I
see is Extended Key Usage, but I don't think that EKU was meant to deal with
algorithm usages.

I do have one question though.  If we go with your proposal, how would
certificates with rsaEncryption in the SubjectPublicKeyInfo
AlgorithmIdentifier be treated?  My suggestion would be that any key
transport method (PKCS #1, OAEP, etc) could be used with these keys.
Anything else would be a redefinition of what that OID meant.  Also, this
would allow people who want to use both algorithms with one key to continue
to do so.  This would mean that id-RSAES-OAEP need only be included in the
subject public key info of certificates whose key is to be used solely with
OAEP, for everyone else nothing changes.

        Robert. 

> -----Original Message----- 
> From: Housley, Russ [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, August 01, 2002 5:01 PM 
> To: [email-masked] 
> Subject: RSA OAEP Public Key Identification 
> 
> 
> 
> At the meeting in Yokohama, we discussed the RSA OAEP draft.  
> One of the 
> areas that was discussed was the security considerations 
> section, where the 
> document recommends that a key pair only be used for one 
> purpose.  Presently, we do not have a mechanism for 
> identifying how a key 
> holder would like to have their public key used. 
> 
> The certificate currently tells the message originator that 
> the public key 
> is an RSA key, and the key usage extension tells that the 
> public key can be 
> used for key transport.  There is nothing to tell the message 
> originator 
> whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a 
> particular 
> key.  So, there is no indication to the message originator 
> that will allow 
> the security consideration to be implemented. 
> 
> 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. 
> 
> This proposal may make transition from RSA PKCS #1 v1.5 to 
> RSA OAEP a bit 
> more difficult, since it would not allow one key pair to be 
> used with both 
> algorithms.  However, this is exactly what the security 
> considerations 
> recommend. 
> 
> Does anyone have concerns with this approach? 
> 
> If this approach is adopted, then a companion document in the 
> PKIX working 
> group for the proper handling of RSA OAEP (and probably RSA 
> PSS) public 
> keys will likely be needed. 
> 
> Russ 
>

---

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 6 Aug 2002 14:41:19 -0700

Hi Robert,

This is about defining policy on how the RSA key is used. Since there is
no scope for this kind of policy in the key usage extension, then EKU is
the intended mechanism. There is nothing in 3280 which restricts the
scope of the kinds usages in EKU to just application policy. The
complication here is that we have a deployed base of applications which
understand one or more existing RSA key OIDs and PKCS#1.5. I agree with
Simon, we should use a new OID for the RSA keys which indicates that if
you use this key with this OID you must understand the range of possible
policies that may be expressed in the EKU extension. If you are OK with
the key being used for both PKCS#1.5 and OAEP the use the existing key
OID with no EKU. We don't have to mark anything critical which is always
a loose cannon, we can just do this by mandate.

Trevor

-----Original Message-----
From: Robert Zuccherato [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2002 1:16 PM
To: 'Simon Blake-Wilson'; 'Housley, Russ'; [email-masked]
Subject: RE: RSA OAEP Public Key Identification

1.  The PKIX Certificate and CRL profile (RFC 3280) has the following
text describing EKU:

	If the extension is present, then the certificate MUST only be
used for one of the purposes indicated.  If multiple purposes are
indicated the application need not recognize all purposes indicated, as
long as the intended purpose is present.  

2.  In my opinion EKU was meant to identify application-level purposes
for which the key may be used, not algorithm-level purposes.  Looking at
the purposes defined in RFC3280 confirms this (server auth., client
auth., code signing, email protection, time stamping, OCSP signing).
Algorithm usages belong in the subjectPublicKeyInfo and placing them in
EKU just unnecessarily complicates things.

	-----Original Message-----
	From: Simon Blake-Wilson [mailto:[email-masked]]
	Sent: Tuesday, August 06, 2002 9:31 AM
	To: 'Robert Zuccherato'; 'Housley, Russ'; [email-masked]
	Subject: RE: RSA OAEP Public Key Identification

	Can one of you please expand on "Why not EKU?" (Since I included
it in all the ECC stuff, if there's a good reason why not, maybe we can
change things.) Naively it seems like EKU has a bunch of nice properties
... for example you can use it to place the policy decision on the
private key holder or the public key holder with the criticality flag,
you can acknowledge that using keys with multiple algs happens and at
least make you the keys are only used with the OIDs listed, you have a
reasonable migration path by making the extension non-critical
initially, etc. Is it just lack of support for EKU in PKI products that
makes introducing a new OID in subjectPublicKeyInfo desirable?

	Best regards. simon

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Zuccherato
	Sent: Friday, August 02, 2002 9:41 AM
	To: 'Housley, Russ'; [email-masked]
	Subject: RE: RSA OAEP Public Key Identification

	Russ; 

	I think that including the id-RSAES-OAEP be used in the
certificate subject public key info field is the right way to go.  The
only other option that I see is Extended Key Usage, but I don't think
that EKU was meant to deal with algorithm usages.

	I do have one question though.  If we go with your proposal, how
would certificates with rsaEncryption in the SubjectPublicKeyInfo
AlgorithmIdentifier be treated?  My suggestion would be that any key
transport method (PKCS #1, OAEP, etc) could be used with these keys.
Anything else would be a redefinition of what that OID meant.  Also,
this would allow people who want to use both algorithms with one key to
continue to do so.  This would mean that id-RSAES-OAEP need only be
included in the subject public key info of certificates whose key is to
be used solely with OAEP, for everyone else nothing changes.

	        Robert. 

	> From: Housley, Russ [mailto:[email-masked]]

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 07 Aug 2002 17:55:30 -0400

Robert:

Your suggestion is consistent with RFC 3279, and I support it.

Russ

At 10:41 AM 8/2/2002 -0400, Robert Zuccherato wrote:

>Russ;
>
>I think that including the id-RSAES-OAEP be used in the certificate 
>subject public key info field is the right way to go.  The only other 
>option that I see is Extended Key Usage, but I don't think that EKU was 
>meant to deal with algorithm usages.
>
>transport method (PKCS #1, OAEP, etc) could be used with these 
>keys.  Anything else would be a redefinition of what that OID 
>meant.  Also, this would allow people who want to use both algorithms with 
>one key to continue to do so.  This would mean that id-RSAES-OAEP need 
>only be included in the subject public key info of certificates whose key 
>is to be used solely with OAEP, for everyone else nothing changes.
>
>         Robert.
>
> > From: Housley, Russ 
> [<mailto:[email-masked]>mailto:[email-masked]]