[cabf_validation] nameConstraints on technically constrained sub-CAs

[Dimitris Zacharopoulos (HARICA)]

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 7.1.2.4 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 
definition of

"*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 
Certificates."

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 7.1.2.4, 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 
https://archive.cabforum.org/pipermail/validation/2021-September/001689.html

but the discussion about 7.1.2.4 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 7.1.2.4. 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.

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