[cabf_validation] nameConstraints on technically constrained sub-CAs

[Dimitris Zacharopoulos (HARICA)]

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 <mailto: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 anyExtendedKeyUsageor 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 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.

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

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

I support this statement. The certificate that is signed by a Root 
subject to the BRs must be well-formed. I was commenting on whether the 
NC extension is required or not for a non-TLS issuing CA. If a CA 
chooses to add a NC, it should be well-formed according to RFC5280.

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

Totally onboard with that which is why I am sharing these thoughts and 
past experience on this topic.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210902/a249f897/attachment.html>