[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Kelvin Yiu kelviny at exchange.microsoft.com
Fri Nov 21 17:32:10 UTC 2014

In theory either approach works. In practice (at least based on my own experience anyway), auditors do not audit against browser requirements, so I think the BR (or another CABF doc) should explicitly state the audit scope since BR requirements are more likely to be followed by auditors. 

I think the browsers' intent has already been to ensure all subCAs under the root CAs we accept are audited but the audit cost is an issue. In additional to clarifying the scope and applicability of audit, we also need a way for auditors to easily verify whether an unconstrained subCA has not be used to issue certain types of certificates that would put the subCA in scope of a specific and potentially more expensive audit. The idea of defining an SSL certificate would fit nicely into this model.


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Friday, November 21, 2014 3:43 AM
To: Ryan Sleevi; Kelvin Yiu
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

On 21/11/14 03:20, Ryan Sleevi wrote:
> While I wish it was true that Section 17 covered it, the loophole is 
> in Section 1 - "This version of the Requirements only addresses 
> Certificates intended to be used for authenticating servers accessible 
> through the Internet"
> That is, if you don't meet Section 1's Scope, surely Section 17's 
> audit requirements don't apply - or so the argument goes. Aligning 
> Section 17 with Section 1 is needed, but as multiple CAs have raised 
> during the past meetings, that means that all of their (code signing, 
> e-mail, etc) certs would fall under the criteria of Section 17. So we 
> need a way to make Scope 1 inclusive (measured by capability, not 
> intent, like Section 17), but also sufficiently exclusive (such as 
> using id-kp-serverAuth) that the existing (code signing, email, etc) 
> intermediates don't run afoul OR are entirely covered by the audits.

The BRs are only relevant because root programs enforce them. And root programs can decide on the scope over which they decide to enforce their application. So are you saying that the BRs should propose a concrete scope based on the principles you've outlined, and the root programs would then say "our scope for BR audits is the scope defined in the BRs"
(or something else, if they wanted something else)?


More information about the Public mailing list