[cabfpub] Issuers in BR/EV/EVCS Guideline Scope

Peter Bowen pzb at amzn.com
Fri Apr 15 04:22:28 UTC 2016

> On Apr 14, 2016, at 7:57 AM, Ryan Sleevi <sleevi at google.com> wrote:
> On Apr 14, 2016 7:35 AM, "Peter Bowen" <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> >
> > The CA/Browser Forum has published three major Guideline documents: the Baseline Requirements, Extended Validation, Guidelines, and Extended Validation Code Signing Guidelines. None of these include clear statements of their scope.  There have been several attempts to define when an issuer is in scope that have resulted in no action due to some gray areas.
> >
> > Instead, I would like to try to get consensus on issuers explicitly not in scope.  My view is that “scope” is something that flows via CA certificates:
> > - Scope starts when a CA (Distinguished Name & Public Key) is included by at least one browser adopting the BRs
> >   - I know that Mozilla and Microsoft have adopted these.  I’m not clear if any other programs have adopted them.
> > - Scope is conferred by a CA in scope issuing a CA certificate to another CA (different Distinguished Name or Public Key)
> >   - CA Certificate is a certificate that has at least one of Basic Constraints with CA:TRUE, keyCertSign key usage, cRLSign key usage
> >
> > I think the following two things are clearly cases when scope does not confer:
> > - Scope is not conferred after the notAfter date in the CA certificate (scope expires)
> > - Scope is not conferred if the CA certificate includes a properly formed Extended Key Usage extension and the listed key purposes do not include any of {anyExtendedKeyUsage, id-kp-serverAuth, id-kp-codeSigning}
> >
> > I know some PKIs view X.509/PKIX as stating that the EKU defines how the pubic key in the certificate can be directly used rather than as a constraint.  I don’t know of a standardized key purpose for certificate signing, but if there is one, it should join the other three as things that don’t prevent scope from conferring.
> >
> > Does anyone disagree that these two are clear cases when scope does not confer?
> >
> > Thanks,
> > Peter
> >
> I agree those are the two clear cases of scope being limited.
> One less-clear case is Technically Contained Sub-CAs, or, in general, name constrained CAs. Some programs declare these out of scope (Mozilla), while some programs, by inheriting the BRs, declare them in scope (Microsoft)
> As structured in the BRs, they are in scope for compliance, but out of scope for third-party audits; instead, issuing CAs are responsible for performing the sampling audits.
> This is meaningful to consider as to whether an issuing CA would expect a qualified audit if a TCSC for "example.com <http://example.com/>" issued a certificate for "Google.com". According to Mozilla requirements, such a cert is not in violation of its program requirements, due to being non-functional for Google.com in Mozilla applications (much like the EKU discussion), while to Microsoft, it is a BR violation that flows upwards from the TCSC to the Issuing CA
I would support some level of relaxation of requirements for CAs that are both name constrained and scoped to key purposes that are known to have name constraints (i.e. technically constrained).  I think might be worth considering what allowances are appropriate.

I also think it is worth considering how to handle the areas in the middle, including:
- CA certificates which are listed as revoked in a CRL and/or where the named OCSP responder responds with revoked state
- CA certificates with anyEKU KP but not id-kp-serverAuth or id-kp-codeSigning
- CAs that were formerly included in a browser program but removed
- CAs used as trust anchors with an “expired" self-signed certificate

However I would hope that there can be agreement on the clearly out-of-scope areas in the near term.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160414/2c503d8a/attachment-0003.html>

More information about the Public mailing list