[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

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

>
>
> On 2/9/2021 6:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Thu, Sep 2, 2021 at 4:41 AM Dimitris Zacharopoulos (HARICA) via
> Validation <validation at cabforum.org> wrote:
>
>> Whether NC is REQUIRED or not for a non-TLS subCA (a Certificate with
>> basicConstraints cA:true and EKU extension with KeyPurposeID that DOES NOT
>> include anyExtendedKeyUsage or id-kp-serverAuth) to be considered
>> "Technically Constrained", has been clarified at least in the Mozilla
>> Root Program since 2016
>> <https://groups.google.com/g/mozilla.dev.security.policy/c/f5-URPoNarI/m/PVdH28BFAAAJ>.
>> It is not required.
>>
>> In fact, HARICA was reading 7.1.5 in the very strict way that Ryan is
>> suggesting, and our first Technically Constrained subCAs, even those that
>> only had the KeyPurposeId of id-kp-emailProtection, ALSO had a NC extension
>> with denied subtrees for dNSName and IPAddress values. After discussions
>> with the Mozilla Root store Managers, it was determined that it was not
>> necessary to add the NC if the subCA had an EKU extension and did not have
>> the id-kp-serverAuth or the anyEKU KeyPurposeId for them to be considered
>> Technically Constrained.
>>
>
> I'm not sure I understand your reply here.
>
> Are you trying to say that CAs are free to ignore the BRs if one root
> program says so?
>
>
> No. I am saying that it's a reasonable interpretation of the current BRs
> and that a subCA that contains an EKU without id-kp-serverAuth or anyEKU
> should be considered technically constrained because it cannot create a
> valid TLS end-entity certificate. Or, put differently, even if a TLS
> end-entity certificate is issued, it should not validate successfully
> because of the EKU chaining restrictions.
>

I fail to see how you can say that "Because one program said something",
that it's fine to reinterpret the BRs according to that.

Apple doesn't implement EKU chaining, and so the BR requirement makes sense
given Apple's implementation. I really must push back on this, because I
want to make sure that CAs aren't arguing that a given program can _loosen_
the BRs arbitrarily. They may choose to ignore a violation for their own
program, as is their prerogative, and we absolutely see programs put more
stringent requirements in their programs than the BRs, but I don't believe
we can say that "Mozilla said it was OK, so now it's OK for everyone" is
somehow acceptable.


> I can understand wanting to talk about what the _future_ requirements
> should say, but I think the context of what the _current_ requirements
> require is relevant here, since the concern is the profiles expressing that
> requirement.
>
>
> I am talking about the current requirements.
>

OK, then you need to support your argument with the current BRs, and not
one Root Program.


> 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210902/3e194d78/attachment-0001.html>