[Servercert-wg] Draft Ballot for Cleanups

[Dimitris Zacharopoulos (HARICA)]

On 2019-10-21 7:31 μ.μ., Ryan Sleevi wrote:
>
>
> On Mon, Oct 21, 2019 at 11:57 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     I was looking at
>     https://github.com/cabforum/documents/compare/master...sleevi:2019-07-Cleanups
>
>     You changed the definition of the Test Certificate in section
>     1.6.1 to say "A Certificate which is issued under a CA where there
>     are no certificate paths/chains to a root certificate subject to
>     these Requirements."
>
>
>     I pointed out the fact that there can be cases where an
>     Intermediate CA Certificate acts as a Trust Anchor and not a root.
>
>
> I'm still not sure why "Trust Anchor" is relevant to the discussion 
> here, unless the idea is that one or more Root Programs would add an 
> intermediate, as a Trust Anchor, subject to these Requirements, while 
> also not having any path to any other certificates subject to these 
> requirements.
>
> Is that your intended scenario? Everything else seems to be wholly 
> covered.

The "Trust Anchor" is relevant because it is linked to the definition of 
the "Publicly-Trusted Certificate". I suppose adding the possibility for 
an intermediate CA to act as a Trust Anchor probably creates additional 
unnecessary complexity. If I understood the expectations of "Test 
Certificates" (in the broader sense), they are not to be considered 
Publicly-Trusted, ever. Is that an accurate assumption?


>     I am aware of the issues created from that definition when it was
>     linked to 3.2.2.4.9. This is an example of things we want to avoid
>     going forward, especially when we describe "extensions" with
>     specific OIDs, without providing ASN.1 module like we've done in
>     the EV Guidelines for .onion and other extensions. In any case, if
>     you and Wayne want to change the definition of the "Test
>     Certificate" to be widely scoped and not specifically for
>     3.2.2.4.9 (which I also support), then my proposed language may be
>     useful for you. In the meantime, for the cleanup ballot, since
>     method 3.2.2.4.9 is deprecated, I suggest we remove this
>     definition and re-introduce it in a future ballot.
>
>
> I think this misunderstands.
>
> My original proposal was to remove this definition entirely - 
> https://github.com/cabforum/documents/commit/b84f020b3d1314059b0ec6bc1c293b5ac7e9fc70
> Wayne suggested it'd be useful to keep part of it, to avoid any 
> confusion from it's complete omission - 
> https://cabforum.org/pipermail/servercert-wg/2019-October/001215.html
> So I re-added it - 
> https://github.com/cabforum/documents/commit/4c7ea8675244632df0e449b5db4c0dabde244dbe
>
> The purpose is not to allow it in more places. The purpose was to 
> avoid the possibility that the complete removal would lead some CAs to 
> incorrectly assume that, because the BRs do not state any rules on 
> "Test Certificates", there are no rules. This is quintessentially 
> "Default-Deny" vs "Default-Allow". The correct reading is 
> "Default-Deny", which aligns with Root Program requirements. However, 
> assuming that the omission of a discussion about "Test Certificates" 
> means they're permitted would be a mistaken application of 
> "Default-Allow".
>
> Until that's resolved, having some definition would appear to cover 
> both scenarios - deny and allow.

Sounds good. That's what I had in mind when I suggested :

"**Test Certificate**: A Certificate which is issued under a CA where 
there are no certificate paths/chains to a CA Certificate, subject to 
these Requirements. A Test Certificate must never be considered a 
Publicly-Trusted Certificate."

So, you can choose either my proposed language or Wayne's. I think 
Wayne's definition might still allow for cases where a CA creates a new 
hierarchy which is still not publicly-trusted (as described in paragraph 
1.1) because it will not be trusted by any Application Software 
Supplier, and issue test certificates without doing proper validations, 
etc. By adding the expectation that a Test Certificate must never (under 
no circumstances), ever be a Public-Trusted Certificate, it is clear 
that this needs to be in a separate hierarchy that can never be linked 
to a publicly-trusted one. In any case, I have no strong feelings about 
this.

>>         I also find the first paragraph of 1.1 problematic "The
>>         requirements are not mandatory for Certification Authorities
>>         unless and until they become adopted and enforced by
>>         relying-party Application Software Suppliers". I don't think
>>         this meets the current expectations, but that's an issue to
>>         discuss separately.
>>
>>
>>     It's exactly how it is. I totally welcome a separate discussion,
>>     but this seems important and something we should stress. The BRs
>>     are not a thing in and of themselves. They are an instrument for
>>     the Root Programs to use, adopt, expand, and modify. Their
>>     legitimacy, and utility, is derived from Root Programs that use,
>>     enforce, and audit against them (and any other requirements they
>>     may add)
>
>     My concern is not about the Root Programs but about the
>     expectations of this community. It would be wrong for any CA to
>     assume that when a CA generates a Root Key-Pair and a RootCA
>     Certificate, the Baseline Requirements DON'T APPLY UNTIL that Root
>     CA is trusted by an Application Software Supplier. Perhaps I am
>     reading this paragraph wrong.
>
>
> Isn't that exactly what Root Programs clarify? That things are subject 
> to the BRs from moment of creation?

The BRs are supposed to be guidelines for CAs that want to issue 
publicly-trusted certificates and for Relying Parties to be able to 
verify these Certificates. We want good guidance to come from these 
documents as if there were no Root programs. If the BRs were "perfect", 
some Root programs wouldn't need to have additional requirements. When 
we spot something ambiguous or problematic in the CA/B Forum guidelines, 
we try to address those by proposing ballots and get consensus from CAs 
and Browsers. CAs and Browsers are working together in this process.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191021/19f05841/attachment-0001.html>