Subject: RE: part1-11

From: Sharon Boeyen <[email-masked]>
Date: Mon, 5 Nov 2001 14:20:56 -0500

Russ, I'm not sure I understand your proposal and I'd also like to add 
a bit to what has taken place since the events you covered in the
background.

Background
----------

Yes, the resolution of DR 244, addressing the criticality flag, had an
impact 
on the EKU extension. That was recognized during the editing meeting that
resolved 
that DR and there was communication between that meeting (Geneva in Feb 01
and Tim 
Polk regarding the PKIX profile and impact). The action taken during that
meeting, 
by the 509 group was to generate a DR specifically on the EKU extension to
preserve
the ability to have it be an "information only" extension in some
environments and 
a required usage flag in others. Given that the resolution of DR 244 means
that 
a relying party system that understands an extension must process it,
regardless 
of its criticality, we tried to find another way to flag the "information
only" 
nature PKIX needed for EKU. The resolution that was recommended out of that
meeting 
was to define a standardized OID that represented (any extended key usage)
and would 
be a wildcard that could match any value in a way similar to the
standardized OID 
for any certificate policy. While the meeting was still going on we learned
that Tim 
was not comfortable with that solution, but I don't believe any others were
suggested.
The meeting produced a Defect Report with its suggested resolution, but we
anticipated 
there would be objections and probably alternative solutions that would come
forward.

If you go back to the PKIX msg list archive, on Feb 22 2001 you will find a
message 
from Hoyt informing PKIX of the new DRs, including this one. That email
states that we were
waiting 2 weeks before submitting these to ISO (in anticipation of further
changes). However,
no discussion happened, the DRs were submitted, NO comments or objections
were received and 
they were approved. So the current status for X.509 is that the OID 2 5 29
37 0 represents
"anyExtendedKeyUsage" in an attempt to address the PKIX requirement for OIDs
in EKU to be 
informational. 

What next
---------

I want to be sure I understand your intent when you say the PKIX text
doesn't need to 
change. Do you mean that PKIX will not adopt the resolution to DR 244 on
criticality? If that's 
the case, I'm very surprised because that DR actually came out of some PKIX
issues, if I remember
correctly. Do you mean that PKIX doesn't want to profile use of the special
OID that was created 
out of DR 275? 

My opinion is that DR 244 is a fundamental and very important DR. It had an
unintended impact on 
EKU. If the resolution of DR 275, which attempted to resolve that, is flawed
then I'd rather look 
at how to address that problem so that 509 and PKIX maintain their
alignment. 

Sharon  

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Thursday, November 01, 2001 2:22 PM
> To: Peter Sylvester
> Cc: [email-masked]
> Subject: Re: part1-11
> 
> 
> 
> Peter:
> 
> First, I will provide some background, then I will respond to 
> the issue 
> that you raise.
> 
> The extended key usage extension was invented to meet 
> Internet community 
> requirements.  Then, X.509 included the extension in the next edition.
> 
> RFC 2459 and Son-Of-2459 contain the following text in the 
> discussion of 
> extended key usage:
> 
>     If the extension is flagged non-critical, then it indicates the
>     intended purpose or purposes of the key, and MAY be used 
> in finding
>     the correct key/certificate of an entity that has multiple
>     keys/certificates.  It is an advisory field and does not 
> imply that
>     usage of the key is restricted by the certification 
> authority to the
>     purpose indicated.  Certificate using applications MAY 
> nevertheless
>     require that a particular purpose be indicated in order for the
>     certificate to be acceptable to that application.
> 
> In your earlier message, you said:
> 
>     ... it seems to me that there has been a change in X509. 
> See defect
>     record 244 and also 275.  It is essentially: When you support an
>     extension, You don't treat is differently depending on whether the
>     critical bit is set.
> 
> X.509 4th Edition Draft V8 includes the following text in the 
> discussion of 
> extended key usage:
> 
>     This extension may, at the option of the certificate 
> issuer, be either
>     critical or non-critical.
> 
>     If the extension is flagged critical, then the 
> certificate shall be used
>     only for one of the purposes indicated.
> 
>     If the extension is flagged non-critical, then it 
> indicates the intended
>     purpose or purposes of the key, and may be used in finding the
>     correct key/certificate of an entity that has multiple 
> keys/certificates. If
>     this extension is present, and the certificate-using 
> system recognizes
>     and processes the extendedKeyUsage extension type, then the
>     certificate-using system shall ensure that the 
> certificate shall be used
>     only for one of the purposes indicated.  (Using applications may
>     nevertheless require that a particular purpose be 
> indicated in order
>     for the certificate to be acceptable to that application.)
> 
>     If a certificate contains both a critical key usage field 
> and a critical
>     extended key usage field, then both fields shall be processed
>     independently and the certificate shall only be used for a purpose
>     consistent with both fields. If there is no purpose 
> consistent with both
>     fields, then the certificate shall not be used for any purpose.
> 
> It is pretty clear that this is an area where are out of 
> alignment.  I 
> spoke with Tim Polk about this situation today.  We think 
> that the revised 
> extended key usage extension no longer meets the original Internet 
> community requirements.  In particular, we are concerned that 
> the inclusion 
> of a non-critical extended key usage extension in a certificate could 
> prevent its use in two otherwise compatible applications.  
> This would occur 
> if one of those applications required the presence of a 
> particular extended 
> key usage OID and the other application does not define any 
> extended key 
> usage OIDs (such as S/MIME).
> 
> With all of this background, Tim and I do not think the Son-Of-2459 
> extended key usage text should be changed.
> 
> Russ
>