[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

Tim,

I want to highlight your reply is fairly unproductive, because it neither
shares new information nor new perspective, and ignores several replies. I
can understand in a fast-moving thread, it can be hard to read everything,
but I want to acknowledge some of your points:

1) "Doug is right"

https://cabforum.org/pipermail/servercert-wg/2019-October/001171.html

> I'm trying to
> clarify that Google's expectation here is that everything that is not
> explicitly permitted is denied. This is, in our view, the only
> internally-consistent way to read the BRs, and the only way to read the BRs
> as meeting our expectations of providing a defensible security boundary and
> way to reason about CA behaviour.


2) This is how standards work. The requirements are the requirements.

This is one of those statements that is neither provably true nor
falsifiable. Some standards work that way, yes; where the place certain
requirements, and everything not listed is permitted. Other standards do
not work that way; if it's not permitted, it's forbidden.

Perhaps CAs will be most familiar with their CP/CPS. For example, DigiCert
recently shared their certificate profile:
https://content.digicert.com/wp-content/uploads/2019/07/Digicert-Certificate-Profiles.pdf
. One way to read that is "These are the only extensions DigiCert will
include" (Default-Deny). Another way of reading this is that "These are the
only extensions DigiCert has rules about; it may include anything else,
without specifying any rules." (Default-Allow).

Now compare that with another CA's CP/CPS, such as Sectigo's
https://sectigo.com/uploads/files/Sectigo-CPS-v5.1.5.pdf , in Appendix C
and Appendix D. One way to read that list of profiles is "These are the
only profiles that Sectigo will include" (Default-Deny). Another way of
reading this is that "These are the only profiles Sectigo has rules about,
without specifying any rules" (Default-Allow).

I highlight this, because CA's should be intimately familiar with the
notion that "If we don't say we do it, we don't do it" when approaching
their CP/CPS. We similarly know the Baseline Requirements are structured in
a way to align with that. If it does not say it is done, then it is not
done.

Blanket statements, like this reads as, don't help advance the
conversation, because they're simultaneously false and true, but only in
some cases: which would mean they're false for all cases. This is where the
sort of 'absolutes' are unhelpful.

3) I can rephrase the remainder of what you said, and it's just as true and
just as helpful as your statement. Namely:

"If any aspect of certificate issuance needs to be permitted, the
permission needs to be explicitly stated in the Baseline Requirements so
that everyone is clear what they are. This is how things have always worked
in the Baseline Requirements"

Note: I took out "and every other standards document" because that's easily
shown as false, and not helpful.


Again, echo'ing the comments from
https://cabforum.org/pipermail/servercert-wg/2019-October/001169.html :

We're sharing the expectation. We've shared this expectation in the past:
e.g. when CAs issued MITM certificates. This is not a new requirement, as
shown with SC16 and expanded on in
https://cabforum.org/pipermail/servercert-wg/2019-October/001171.html .

Now, if folks feel the Baseline Requirements are not clear about this,
we're happy to clarify the Baseline Requirements. If folks don't want it
clarified via the Baseline Requirements, we're happy to clarify it via Root
Policy. However, the expectation remains.

Further, if this causes issues, we're happy to discuss issues CAs identify.
We don't think this should break anything, but if folks identify things
that consistently applying a view of Default-Deny would deny, which they
believe should be allowed, it'd be good to raise those, just like we saw
with 3.2.2.4.

Again, I want to make sure we're focusing on the systemic issue, not
individual CAs. Our expectation is Default-Deny. There are a set of CAs not
consistently applying this. We believe it's because they're reading the BRs
as Default-Allow, even though the BRs don't internally support that view.
We'd like to clarify in the BRs. We would love CAs, particularly the CAs
impacted, to suggest language that they feel would make it clearer. We're
happy to address this via Root Program requirement. However, we do not see
Default-Allow as being an acceptable way to read the BRs, and want to
ensure this approach is made clear to CAs as problematic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/4baa0482/attachment.html>