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

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Fri Apr 15 18:55:43 UTC 2016

Peter - you have addresses a lot of issues at a very abstract level.  I'm curious -- is there a current problem or need you are addressing?  (If so, can you describe so we all have context?)  Or are you approaching this more from an intellectual perspective, simply trying to set limitations which might be useful in the future if we have a question about the scope of various guidelines?

Also -- does this indirectly tie into the work of the new Governance Change Working Group - meaning, does the proper scope of any guidelines tie into the proper scope of the work and membership of the Forum?

I am wary of adopting new rules in the abstract without having a better understanding (including examples, if possible) of exactly what problem we are addressing.   Otherwise, we could adopt a limitation only to discover that we didn't like it when a particular situation arises (Gerv gave a good example)

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
Sent: Thursday, April 14, 2016 7:35 AM
Subject: [cabfpub] Issuers in BR/EV/EVCS Guideline Scope

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?

Public mailing list
Public at cabforum.org

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

More information about the Public mailing list