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

[Dimitris Zacharopoulos (HARICA)]

On 2020-03-04 7:46 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Mar 4, 2020 at 10:35 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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.
>

They are not just "declared" out of scope, they are technically 
incapable of issuing TLS Certificates. This is not based on "intent" as 
we have seen previously being discussed.

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

Using technically constrained subCAs (by EKU) to enforce "scope" was a 
way to solve the "intent" problem. I fully agree with you that "intent" 
is a weak argument that CAs should not use to justify deviations from 
the requirements.

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

Cross-certified paths are much easier to build and implement in TLS but 
quite harder for S/MIME. At least we agree on setting a good practice 
forward, where CAs create "clean TLS" hierarchies using cross-certified 
paths with older hierarchies. That doesn't quite solve the existing 
ambiguity problem, because these "old" hierarchies must be operational, 
but in a couple of years we could be looking at native-TLS hierarchies 
in the WebPKI.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200304/67ac9fc2/attachment-0001.html>