[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

On Mon, Oct 21, 2019 at 11:57 AM Dimitris Zacharopoulos (HARICA) <
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.


> 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.


> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191021/c9ce7d16/attachment.html>