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

[Ryan Sleevi]

On Apr 14, 2016 7:35 AM, "Peter Bowen" <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" 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160414/205d8e51/attachment-0003.html>