[cabfpub] Name Constraints, Auditing and EKU

Tue Apr 23 20:32:24 UTC 2013

Windows, Office, and IE is one such product.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Brown, Wendy (10421)
Sent: Tuesday, April 23, 2013 1:10 PM
To: Rob Stradling; Piyush Jain
Cc: public at cabforum.org
Subject: Re: [cabfpub] Name Constraints, Auditing and EKU

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

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public