[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

On Thu, Sep 2, 2021 at 2:19 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> If a Browser (especially the Mozilla Root Program which is based on an
> open community where industry experts and security researchers contribute)
> has a certain interpretation of the BRs, this does have some weight in the
> industry. The same thing applies when you, representing Google Chrome, have
> a certain interpretation of the BRs that some CAs find ambiguous.
>

Again, I'm asking you to support your interpretation with the BRs.

You're basically saying "Mozilla didn't get upset at us", and you're not
referencing any of the BRs or the subsequent discussions.


> If I understand correctly, you are arguing that Mozilla is relaxing a BR
> rule without doing so in their Root Program Policy and I am saying that
> this is one possible interpretation of the current BRs.
>

You're not actually arguing that though, as that would imply you've given
some evidence to support your conclusion. You haven't addressed any of the
substance, you've just said "Well, no, Mozilla said so". I realize this
might seem very direct, but I think it's absolutely critical that if you're
going to argue something is a valid interpretation of the BRs, you at least
need to show your work.


> Mozilla didn't interpret the BRs like you did and said "we don't care if
> you violate that requirement". They didn't see it as a violation, ever. And
> so did the auditors of all CAs out there that have used the same Root
> hierachy for non-TLS certificates, otherwise we would have seen audit
> reports with incidents highlighting that issue.
>

I'm sorry, is this the "Well, our auditor didn't say anything, so this must
not be a violation"?

Again, show your work :)


> I mentioned the Mozilla communications because we are talking about
> industry experts and security researchers who are reading the BRs, just
> like everyone else. Their opinion has some weight in the interpretation of
> the BRs and CAs often seek clarifications and interpretations in the
> m.d.s.p. community.
>

It has relevance to Mozilla's program, but we're talking about the BRs.


> Taking the current BRs, in section 7.1.5, reading from the top:
>

Let's refer back to the original message:
https://archive.cabforum.org/pipermail/validation/2021-September/001689.html
, so you can make it clear which point you disagree with.

> "For a Subordinate CA Certificate to be considered Technically
> Constrained, the certificate MUST include an Extended Key Usage (EKU)
> extension specifying all extended key usages that the Subordinate CA
> Certificate is authorized to issue certificates for. The
> anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension."
>
Yes. This is #1, #2, and #3.

> Let's pick anything but "id-kp-serverAuth". Moving to the next paragraph:
>
> "If the Subordinate CA Certificate includes the id-kp-serverAuth extended
> key usage, then the Subordinate CA Certificate MUST include the Name
> Constraints X.509v3 extension with constraints on dNSName, iPAddress and
> DirectoryName as follows:"
> Not applicable because we do not have "id-kp-serverAuth". BTW, the
> rendering of a. b. c. under that paragraph doesn't render properly on
> GitHub Markdown flavor :)
>

Yes, this is #7 - #9, which we agree with.


> The rest of the section describes requirements for Name Constraints IF
> they are required. One can read it as they are only required "If the
> Subordinate CA Certificate includes the id-kp-serverAuth extended key
> usage" because that is clearly written in the second paragraph. The intent
> about NCs is unclear for subCAs that do not have the id-kp-serverAuth
> extended key usage.
>

It appears you disagree with the #10 - #13 here. You're saying that this
section "only" applies for id-kp-serverAuth.

This is not how this section reads, but it also means you've ignored the
Section 7.1.2.4 requirements here, as well as those in Section 1.6.1. Could
you explain why you believe it's OK to ignore these?

You will note, for example, that the profiles work is trying to relax this
>> and actually allow the EKU-or-NC.
>>
>>
>> If the SCWG is looking it from the server TLS point of view, "technically
>> constrained" should focus on the technical capabilities of validating a
>> trust path that would enable a *server TLS* end-entity certificate. In
>> the attempt to describe the profiles for TLS and non-TLS issuing CAs, and
>> as the certificate profiles work is trying to clarify, for the first case
>> we should need both EKU (serverAuth) and NC, while for the non-TLS we
>> should constrain with just the EKU (must not include serverAuth or anyEKU).
>>
>
> As mentioned above, that's *not* reflective in current Browser members
> applications behave. This is why the current language requires the And, and
> doesn't say Or. The "id-kp-serverAuth" EE cert from an
> "id-kp-emailProtection" will validate in RFC 5280-only implementations,
> and, for Apple's case, will validate in Apple's supported implementations.
> So yes, it matters :)
>
>
> The IF statement of the second paragraph has a MUST for the NC extension,
> only if the keyPurposeId is "id-kp-serverAuth".
>

Yes, we're not disagreeing here.

You appear, however, to be taking that "If" clause to also extend to each
subsequent paragraph, despite that being contrary to the Definition of a
Technically Constrained Sub-CA, and despite the requirements of 7.1.2.4. I
don't understand how or why you're reaching that conclusion, other than
saying "Well, Mozilla did this for their root program", which, again, seems
largely irrelevant for the BR discussion here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210902/0dadc5e7/attachment-0001.html>