[Servercert-wg] Subject name requirements for CA Certificates

[Curt Spann]

Managing, reading and unfortunately interpreting the BRs as it stands is already pretty onerous and prone to mistakes. If we don’t approach the BRs as Default-Deny in which it only specifies what is allowed, then the document will grow substantially and leave too much wiggly room for interpretations. I also believe if we approach it as Default-Allow, the BRs will see incremental updates in response to bad practices observed instead of a well considered holistic approach. I would prefer to approach the BRs as Default-Deny and then narrowly specify what is allowed.

I would think CAs would be in favor of the Default-Deny approach as it would make it easier (less ambiguous) to determine the requirement for operating a publicly trusted CA and require less interpretation.

- Curt

> On Oct 9, 2019, at 11:22 AM, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org> wrote:
> 
> 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 <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 <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 <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 <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 <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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/93c6eb45/attachment.html>