[cabf_validation] nameConstraints on technically constrained sub-CAs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Sep 2 15:58:48 UTC 2021
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>>
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation