[Servercert-wg] [EXTERNAL]Re: Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)

[Ryan Sleevi]

On Wed, Mar 4, 2020 at 10:35 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> You have added a lot of context to your reply. I've made an honest attempt
> to answer most of your points to the best of my knowledge/understanding.
>
> On 2020-03-03 6:54 μ.μ., Ryan Sleevi wrote:
>
> I would be happy to draft a ballot to clarify this, but I believe Pedro's
> answer is far closer to what we (Google) expects than those answers offered
> by Bruce and Dimitris.
>
> At the very heart of the differing interpretations is this:
> - Do the BRs apply to what a CA in-scope can issue/sign; or
> - Do the BRs apply to what is issued/signed?
>
>
> My understanding all these years is that other sections of the BRs are
> more related to the former and others to the latter. For example, the
> end-entity Certificate Profiles are related to CAs in-scope. This means
> that if a CA is technically capable of issuing a TLS Certificate, it must
> follow all the end-entity Certificate Profile requirements. A Root CA that
> is participating in a TLS hierarchy is definitely in scope of the BRs (we
> even made an update to 6.1.7 to ensure Root Keys are not used to sign
> time-stamping certificates). Once a Root signs a CA that is not technically
> capable of issuing TLS Certificates, then in my understanding that subCA is
> out of BRs scope. Of course, the Root still needs to provide CRLs, OCSP
> services according to the BRs.
>

I'm afraid the important distinction I was trying to highlight was not
realized, then.

Much of your reply focuses on the issuance of end-entities from a
subordinate CA you've declared out of scope. That's not the distinction
being made. It's about what the root can sign - that is, the permissible
subordinate CAs and the expectations.

We've already seen CAs try to cite ambiguity as a reason they were able to
issue completely unacceptable certificates, such as testing certificates,
by trying to claim they were "out of scope" since they "obviously" didn't
conform to the restrictions on SubCAs/Leaves. The suggestion of Scope being
determined by what is signed, rather than Scope being determined by what is
capable of doing signing, is the fundamental flaw here.


> The current practice used by several CAs is to have a single trust anchor
> (Root CA) that issues subordinate CAs for different purposes (TLS, S/MIME,
> Code Signing, Time-stamping, docSigning, etc). Historically some Root
> Programs have advised against adding multiple Root CA Certificates in their
> Root store.
>
> The benefits of completely separate, distinct, hierarchies are very clear
> in terms of compliance enforcement. However, it is extremely difficult to
> achieve this separation with the various Root Programs and the time it
> takes to process Root inclusion requests. The ubiquity problem is also very
> real, so we would be looking at a long-term transition if we were to follow
> that route. Perhaps it would be worth discussing and see how supportive the
> various Root Programs would be to such a change, and also examine possible
> unexpected consequences in separating those hierarchies.
>

The suggestion of the root inclusion processing time, and the ubiquity
problem, are significantly overstated.

CAs can move to explicit transition hierarchies "today" for new issuance,
nothing prevents that. The ubiquity problem is entirely orthogonal, by
having cross-certified paths to the 'old' (existing) CA, while shifting the
hierarchy to a 'new' separation. That is, for situations today, where a
Root CA does (Root -> Intermediate -> Leaf), they can easily, without
difficulty, shift to (Root -> Potential new TLS Root -> Intermediate ->
Leaf, Root -> Potential new S/MIME Root ->  Intermediate -> Leaf). Most
members in the Forum are perfectly capable and regularly do this, as
reflected in their own transition from old roots to new roots. So let's not
conflate the challenge of introducing new organizations (by design,
difficult) with the challenge of introducing new hierarchies (which CAs can
do and regularly)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200304/ccbde27b/attachment.html>