[cabf_validation] nameConstraints on technically constrained sub-CAs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Sep 2 19:12:31 UTC 2021
On 2/9/2021 9:35 μ.μ., Ryan Sleevi wrote:
> 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 220.127.116.11 requirements here, as well as those in Section
> 1.6.1. Could you explain why you believe it's OK to ignore these?
When you are discussing about 1.6.1 I assume you are referring to the
"*Technically Constrained Subordinate CA Certificate*: A Subordinate CA
certificate which uses a combination of Extended Key Usage settings and
Name Constraint settings to limit the scope within which the Subordinate
CA Certificate may issue Subscriber or additional Subordinate CA
Let me first state that I am not a native English speaker and my reading
could have some obvious errors for which I would hope the native English
speakers will correct :)
When it comes to *Subscriber Certificates* the scope of the BRs are
server TLS Certificates. Therefore the definition applies to "within
which*the Subordinate CA Certificate may issue Subscriber* or additional
Subordinate CA *Certificates*", which points to the TLS technically
constrained subCAs for which a combination of EKU AND NC is required, as
described in 7.1.5.
Regarding 18.104.22.168, I'm not sure which part you assume I am ignoring. Is
it the part about RFC 5280 requirements for well-formed fields?
I read your email in
but the discussion about 22.214.171.124 is probably not so clear to me. I will
try to re-read it and hopefully see your points clearer.
>>> 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 126.96.36.199. 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.
I hope my answer gives you some idea how one could come to that conclusion.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation