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:sblakewilson(_at_)bcisse(_dot_)com]
Sent: Tuesday, August 06, 2002 9:31 AM
To: 'Robert Zuccherato'; 'Housley, Russ'; ietf-smime(_at_)imc(_dot_)org
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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Robert Zuccherato
Sent: Friday, August 02, 2002 9:41 AM
To: 'Housley, Russ'; ietf-smime(_at_)imc(_dot_)org
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:rhousley(_at_)rsasecurity(_dot_)com
<mailto:rhousley(_at_)rsasecurity(_dot_)com> ]
Sent: Thursday, August 01, 2002 5:01 PM
To: ietf-smime(_at_)imc(_dot_)org
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