[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Tue, Oct 22, 2019 at 11:51 PM Leo Grove <leo at ssl.com> wrote:

> Kirk,
>
> Before we vote on a "default-deny" application to the BRs, I think it
> prudent to perform a thorough "impact study" of how this might affect other
> areas in the BRs beyond the subject DN. It might open a can of worms unless
> we do this methodically and iron out the unforeseen kinks.
>

Leo,

While I agree with you, and this was captured previous in
https://cabforum.org/pipermail/servercert-wg/2019-October/001178.html , I
do want to reiterate: This is about making it clear the expectations, not
about changing the requirements. The existing expectation is that unless
something is permitted, it is forbidden. As mentioned in the original
message, this is the only reasonable, internally-consistent way in which to
read the BRs, particularly when it gives lists of options.

The discussion is merely about making sure it's clear to CAs. If CAs have
language they'd like to offer that make it clear and unambiguous, we'd
welcome it, and that's the sort of positive collaboration we're looking
for. Similarly, if there are situations where you're aware of that CAs are
doing something not clearly enumerated in the BRs (i.e. in violation of the
BRs), these are good to identify, and on a case-by-case basis, evaluate
whether to allow and/or to allow a graceful transition away from.

However, it is important that the expectation here is that the BRs list how
a CA SHALL behave, not how a CA MAY behave or SHOULD behave. This is the
only way we can reasonably be confident of the risk from trusting a CA, if
we're confident that we have a clear understanding about what they do - and
do not do.

The process, for each CA, should be a matter of reading through the BRs and
asking "Do we do something different than what is explicitly stated?" There
are many places where significant latitude is given to CAs, such as
extensions or in the profiles for OCSP and CRLs, while also places where
very explicit, enumerated sets of requirements are given, such as
algorithms, keys, or security practices. Understanding where a CA differs
from the explicitly written requirements is, of course, essential to
understanding the risk posed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/4ee69469/attachment-0001.html>