[cabfpub] Name Constraints, Auditing and EKU

Brown, Wendy (10421) wendy.brown at pgs.protiviti.com
Tue Apr 23 13:09:33 MST 2013


I would actually be interested in seeing these products that have been using EKU constraints for years pass the PKITS PD-VAL  test suites.  The FPKI community has been finding issues for years with path validation and that is one of the reasons they will continue to use publicly disclosed and audited rather than "technically constrained" cross-certificates.

-----Original Message-----
From: Rob Stradling [mailto:rob.stradling at comodo.com] 
Sent: Tuesday, April 23, 2013 3:58 PM
To: Piyush Jain
Cc: Brown, Wendy (10421); public at cabforum.org
Subject: Re: [cabfpub] Name Constraints, Auditing and EKU

On 23/04/13 18:41, Piyush Jain wrote:
> Rob,

Hi Piyush.

> With all due respect, Stefan, in that thread was referring to state of 
> certificate policy processing 10 years ago.
> Certificate validation implementations have evolved quite a bit since then.

That's true.

> There are umpteen number of use cases being defined in the govt. PKI 
> which depend on correct certificate policy processing. These include 
> determining the level of assurance, and enabling cross-domain 
> transactions. I admit that these use cases are not applicable to CAB 
> use cases where all the RP needs is to establish trust in a TLS 
> server. But following non-standard practices just because it does not 
> conflict with CAB's simple use case is myopic IMO and is bound to 
> cause issues in a different scenario that his forum did not think of.

Agreed.  That's why I tried (unsuccessfully) to persuade Mozilla to require the use of the Netscape Cert Type extension instead of "EKU constraints" (this was last year when the "technically constrained" 
language in the current version of the Mozilla CA Policy was being put together).

If the Mozilla and Microsoft representatives on this list will speak up now in support of deprecating "EKU constraints" in favour of something standards-compliant (or, at the very least, a lot less kludgey), then we may be able to reach consensus on a way forward.
But if not, then I think we're stuck with "EKU constraints".

> One example is the OCSP signing EKU example that I alluded to in my 
> response to Wendy.

Agreed.  We already tackled this a little earlier in the thread, BTW.

> Given that CAB forum defines the BR for both clients and CAs,

Actually, the BRs are "...for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted Certificates."

Browsers and other clients are free to ignore any/all parts of the BRs.

> it has the opportunity to do it correctly and in standards compliant 
> way through a policy constraint or a KU/EKU constraint extension.

One persuasive argument in favour of "EKU constraints" is that they already work with a significant proportion of the deployed clients.  If we define a new cert extension, we'll have to wait N years (until the vast majority of deployed clients support it) before we can actually use it effectively.

I agree that it'd be worth exploring the viability of using Policy Constraints.  I don't know how well these are supported in deployed clients.

The only other option I can think of is that CAs could be required to use _both_ the Netscape Cert Type extension _and_ the Microsoft Application Policies extension for "technically constrained" Sub-CAs. 
AIUI, this would roughly equal "EKU constraints" in terms of widespread support by deployed clients.  The question would be whether or not Mozilla and Microsoft could be persuaded to "un-deprecate" these extensions.

> -Piyush
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public- 
>> bounces at cabforum.org] On Behalf Of Rob Stradling
>> Sent: Tuesday, April 23, 2013 3:14 AM
>> To: Brown, Wendy (10421)
>> Cc: public at cabforum.org
>> Subject: Re: [cabfpub] Name Constraints, Auditing and EKU
>>
>> On 22/04/13 20:49, Brown, Wendy (10421) wrote:
>>> I disagree with the statement it is too late to try to stop the
> proliferation of
>> trying to do technical constraints on CAs using EKU in violation of 
>> the
> intent of
>> RFC 5280.
>>
>> Wendy, you are welcome to try.  Maybe you will succeed where others 
>> have failed.
>>
>> Even Microsoft, the architects of "EKU constraints", were 
>> unsuccessful
> when
>> they tried to move to an alternative mechanism that didn't violate 
>> the
> intent
>> of RFC5280.  See...
>> See http://www.ietf.org/mail-archive/web/pkix/current/msg32431.html
>>
>>> The FPKI is one large community of PKIs that will opt for publicly
> disclosed
>> and audited rather than the technical constraints Mozilla is trying 
>> to
> impose
>> because that model doesn't really work with our community and we 
>> already require audit of all subordinate CAs.
>>>
>>>      wendy
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist COMODO - Creating Trust 
>> Online
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online




More information about the Public mailing list