[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

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?

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.

You will note, for example, that the profiles work is trying to relax this
and actually allow the EKU-or-NC. However, it's still requiring that, even
if a distinct EKU is present, because it's issued from a BR CA, the
certificates the BR CA issues need to be well-formed. That seems to have
some concern raised, by Corey, and that's why we're trying to resolve, by
making sure we have a correct understanding about what the BRs require, so
that we can make sure that the profiles work is properly seen as strictly
relaxing, not adding new restrictions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210902/c41df7d7/attachment.html>