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:robert(_dot_)zuccherato(_at_)entrust(_dot_)com]
Sent: Tuesday, August 06, 2002 1:16 PM
To: 'Simon Blake-Wilson'; 'Housley, Russ'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: RSA OAEP Public Key Identification
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]
> 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
>