[cabfpub] Name Constraints, Auditing and EKU

[Rob Stradling]

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