Subject: Re: [pkix] Ambiguity in 5280 Regarding EKU Processing During Certification Path Processing

From: Stefan Santesson <[email-masked]>
Date: Sun, 01 Nov 2009 18:33:32 +0100

Santosh,

Answers in line:

On 09-10-30 5:46 PM, "Santosh Chokhani" <[email-masked]> wrote:

> All,
> 
> If this is getting into too much detail, I can carry out this as a
> private communication with Stefan.  Let me know.
> 
> Stefan,
> 
> So, let us say that I have one or more CA certificates in a chain
> asserting anyEKU and possibly one or more private EKU.
> 

First of all, anyEKU in a CA certificate is not treated like anyPolicy in
policy path processing. In the current functionality, the way to allow all
EKU settings in the EE cert is to have an absent EKU extension. If the
anyEKU OID is present in a CA certificate, this only means that this CA
certificate allows the EE certificate to assert the anyEKU OID.

> What is happening with respect to Outlook (+CAPI) or IIS (+CAPI) if the
> end certificate does not have an EKU?
> 

If my own notes about this is accurate (it was a while since I investigated
this) then a certificate with an empty set of valid EKUs is still shown as
valid until the application asks whether it is valid for a particular usage.

If the application asks the API whether the certificate in question is valid
for a particular usage, the certificate is valid if that EKU is present and
supported by the path.

> I ask because Outlook and IIS do not require secure e-mail or client
> authentication EKU respectively in the end certificate.  They are happy
> if none are present.
> 

Again, unless the application asks for a RequestedUsage through
CERT_CHAIN_PARA, the certificate will appear valid even if no EKU is
supported.

> Is it the case that they ask CAPI what EKU you got and it says anyEKU
> and they barf?  If CAPI said none, they will be happy????
> 

The application will have to ask if the certificate supports the anyEKU OID
and if CAPI says yes, draw their own conclusion.
The anyEKU  OID is not treated any different than any other EKU OID by CAPI.

/Stefan

>> -----Original Message-----
>> From: Stefan Santesson [mailto:[email-masked]]
>> Sent: Thursday, October 29, 2009 11:00 PM
>> To: Santosh Chokhani; David A. Cooper
>> Cc: [email-masked]
>> Subject: Re: [pkix] Ambiguity in 5280 Regarding EKU
>> Processing During Certification Path Processing
>> 
>> Santosh,
>> 
>> What you say about anyEKU (anyExtendedKeyUsage) is not entirely true.
>> 
>> CAPI does support anyEKU in a compliant manner, but it turns
>> the decision over to the client (as it should).
>> 
>> It is important to understand in this context that anyEKU is
>> fundamentally different from anyPolicy in policy processing.
>> 
>> anyPolicy is a direct substitution for any policy OID in path
>> processing, anyEKU is not. anyEKU just allows the client to
>> accept a certificate for other usages than those explicitly
>> specified by present EKUs.
>> 
>> This is allowed and supported by CAPI.
>> 
>> Example: If the application asks CAPI to check if the EE
>> certificate support EKU A, and the certificate does not
>> support EKU A but does support anyEKU, then this test will
>> fail, saying that the certificate does not match the requested usage.
>> 
>> This is correct since anyEKU does NOT mean that there is a match.
>> 
>> RFC 5280:  
>>   "Applications that require the presence of a
>>    particular purpose MAY reject certificates that include the
>>    anyExtendedKeyUsage OID but not the particular OID expected for the
>>    application."
>> 
>> In this case it is up to the application to subjectively
>> accept anyPolicy as a substitution for EKU A. In order to do
>> this, the application should ask CAPI if the EE certificate
>> supports EKU A OR anyEKU. CAPI would honor this in a 5280
>> compliant manner.
>> 
>> 
>> 
>> Further. This whole EKU issue is a non problem if CA
>> certificates does not contain EKUs. If EKUs are absent in the
>> CA certificates, the EKU processing of CPI turns fully
>> standards compliant. The rarity of EKUs in CA certificates is
>> the reason why this mostly has passed unnoticed.
>> 
>> One could say that CAPI has its own way to interpret the
>> meaning of EKU in CA certificates in addition to standards
>> compliant EKU processing.
>> 
>> On your closing point - I fully agree. One should not put
>> EKUs in CA certificates if you want consistent processing
>> cross platforms.
>> 
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>> On 09-10-30 3:28 AM, "Santosh Chokhani"
>> <[email-masked]> wrote:
>> 
>>> Stefan,
>>> 
>>> What is throwing monkey wrench in this, is that in addition
>> to being 
>>> non-compliant to standards in processing EKU, CAPI does not honor
>>> anyExtendedKeyUsage either.  Thus, for CAPI to succeed, you
>> better not 
>>> put EKU in CA certificates.
>>> 
>>>> -----Original Message-----
>>>> From: Stefan Santesson [mailto:[email-masked]]
>>>> Sent: Thursday, October 29, 2009 10:15 PM
>>>> To: Stefan Santesson; Santosh Chokhani; David A. Cooper
>>>> Cc: [email-masked]
>>>> Subject: Re: [pkix] Ambiguity in 5280 Regarding EKU
>> Processing During
>>>> Certification Path Processing
>>>> 
>>>> 
>>>> It strikes me that the following may require some more explanation.
>>>> 
>>>> On 09-10-30 2:35 AM, "Stefan Santesson" <[email-masked]> wrote:
>>>> 
>>>>> This is not so clearly explained on this page, but the
>>>> choice of AND
>>>>> or OR logic decides whether AND or OR logic is applied to
>>>> the EKU path processing.
>>>>> The OR logic was used when one could expect a mix of old
>>>> Netscape OIDs
>>>>> and new standardized OIDs for e.g. ServerAuth EKU.
>>>> 
>>>> 
>>>> Setting the AND or OR logic is done in the CAPI API call
>>>> (CERT_CHAIN_PARA
>>>> http://msdn.microsoft.com/en-us/library/aa377186(VS.85).aspx
>>>> ) in the following context:
>>>> 
>>>> Ex 1. EKU A AND EKU B
>>>> The target certificate is valid IF EKU A AND EKU B are
>> supported by 
>>>> every certificate in the path (either by explicit EKU setting or
>>>> through absent EKU extension in CA
>>>> certificates)
>>>> 
>>>> Ex 2. EKU A OR EKU B
>>>> The target certificate is valid IF EKU A OR EKU B is
>> supported by the
>>>> path.
>>>> 
>>>> 
>>>> The OR test case is a bit special. To explain further, the
>> OR test is 
>>>> deemed valid in the following path:
>>>> 
>>>> Root: EKU property supports EKU A
>>>> CA 1: absent EKU extension
>>>> CA 2: EKU B in EKU extension
>>>> CA 3: EKU A in EKU extension
>>>> EE cert: EKU A in EKU extension
>>>> 
>>>> The use of the EE certificate is valid for EKU A in this
>> case since 
>>>> the request to the CAPI API asked that the certificate should be
>>>> valid IF each certificate of the path support either EKU A
>> OR EKU B.
>>>> 
>>>> Now this may look extremely strange but the explanation
>> has a grain 
>>>> of logic. If EKU A and EKU B are two separate OIDs for the same
>>>> usage, then the certificate would be valid if each
>> certificate of the
>>>> path supported either of the two valid EKUs.
>>>> 
>>>> Asking CAPI to validate the same path, requesting support
>> for EKU A 
>>>> AND EKU B would fail in the the example above, as that
>> would require 
>>>> EKU A AND EKU B to be supported by all certificates of the path.
>>>> 
>>>> 
>>>> /Stefan
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 1 Nov 2009 15:12:51 -0500

Stefan,

Do you know what IIS and Outlook ask for? 

> Sent: Sunday, November 01, 2009 12:34 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> First of all, anyEKU in a CA certificate is not treated like 
> anyPolicy in policy path processing. In the current 
> functionality, the way to allow all EKU settings in the EE 
> cert is to have an absent EKU extension. If the anyEKU OID is 
> present in a CA certificate, this only means that this CA 
> > What is happening with respect to Outlook (+CAPI) or IIS (+CAPI) if 
> > the end certificate does not have an EKU?
> > 
> 
> this) then a certificate with an empty set of valid EKUs is 
> still shown as valid until the application asks whether it is 
> valid for a particular usage.
> 
> If the application asks the API whether the certificate in 
> question is valid for a particular usage, the certificate is 
> valid if that EKU is present and supported by the path.
> 
> 
> > authentication EKU respectively in the end certificate.  They are 
> > happy if none are present.
> > 
> 
> Again, unless the application asks for a RequestedUsage 
> through CERT_CHAIN_PARA, the certificate will appear valid 
> even if no EKU is supported.
> 
> The application will have to ask if the certificate supports 
> the anyEKU OID and if CAPI says yes, draw their own conclusion.
> >> CAPI does support anyEKU in a compliant manner, but it turns the 
> >> decision over to the client (as it should).
> >> 
> >> processing, anyEKU is not. anyEKU just allows the client 
> to accept a 
> >> certificate for other usages than those explicitly specified by 
> >> present EKUs.
> >> 
> certificate 
> >> support EKU A, and the certificate does not support EKU A but does 
> >> support anyEKU, then this test will fail, saying that the 
> certificate 
> >> does not match the requested usage.
> >> 
> >> In this case it is up to the application to subjectively accept 
> >> anyPolicy as a substitution for EKU A. In order to do this, the 
> >> application should ask CAPI if the EE certificate supports 
> EKU A OR 
> >> anyEKU. CAPI would honor this in a 5280 compliant manner.
> >> 
> >> 
> >> 
> >> Further. This whole EKU issue is a non problem if CA certificates 
> >> does not contain EKUs. If EKUs are absent in the CA 
> certificates, the 
> >> EKU processing of CPI turns fully standards compliant. The 
> rarity of 
> >> EKUs in CA certificates is the reason why this mostly has passed 
> >> unnoticed.
> >> 
> meaning of 
> >> EKU in CA certificates in addition to standards compliant EKU 
> >> processing.
> >> 
> EKUs in CA 
> >> certificates if you want consistent processing cross platforms.
> >> 
> >> 
> >> /Stefan
> >> 
> >> 
> >> 
> >>