[cabf_validation] nameConstraints on technically constrained sub-CAs

Thu Sep 2 18:19:27 UTC 2021

On 2/9/2021 7:36 μ.μ., Ryan Sleevi wrote:
>
>
> On Thu, Sep 2, 2021 at 11:58 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>
>     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 fail to see how you can say that "Because one program said 
> something", that it's fine to reinterpret the BRs according to that.
>
> Apple doesn't implement EKU chaining, and so the BR requirement makes 
> sense given Apple's implementation. I really must push back on this, 
> because I want to make sure that CAs aren't arguing that a given 
> program can _loosen_ the BRs arbitrarily. They may choose to ignore a 
> violation for their own program, as is their prerogative, and we 
> absolutely see programs put more stringent requirements in their 
> programs than the BRs, but I don't believe we can say that "Mozilla 
> said it was OK, so now it's OK for everyone" is somehow acceptable.

If a Browser (especially the Mozilla Root Program which is based on an 
open community where industry experts and security researchers 
contribute) has a certain interpretation of the BRs, this does have some 
weight in the industry. The same thing applies when you, representing 
Google Chrome, have a certain interpretation of the BRs that some CAs 
find ambiguous.

If I understand correctly, you are arguing that Mozilla is relaxing a BR 
rule without doing so in their Root Program Policy and I am saying that 
this is one possible interpretation of the current BRs. Mozilla didn't 
interpret the BRs like you did and said "we don't care if you violate 
that requirement". They didn't see it as a violation, ever. And so did 
the auditors of all CAs out there that have used the same Root hierachy 
for non-TLS certificates, otherwise we would have seen audit reports 
with incidents highlighting that issue.

>>     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.
>
>
> OK, then you need to support your argument with the current BRs, and 
> not one Root Program.

I mentioned the Mozilla communications because we are talking about 
industry experts and security researchers who are reading the BRs, just 
like everyone else. Their opinion has some weight in the interpretation 
of the BRs and CAs often seek clarifications and interpretations in the 
m.d.s.p. community.

Taking the current BRs, in section 7.1.5, reading from the top:

"For a Subordinate CA Certificate to be considered Technically 
Constrained, the certificate MUST include an Extended Key Usage (EKU) 
extension specifying all extended key usages that the Subordinate CA 
Certificate is authorized to issue certificates for. The 
|anyExtendedKeyUsage| KeyPurposeId MUST NOT appear within this extension."

Let's pick anything but "id-kp-serverAuth". Moving to the next paragraph:

"If the Subordinate CA Certificate includes the id-kp-serverAuth 
extended key usage, then the Subordinate CA Certificate MUST include the 
Name Constraints X.509v3 extension with constraints on |dNSName|, 
|iPAddress| and |DirectoryName| as follows:"

Not applicable because we do not have "id-kp-serverAuth". BTW, the 
rendering of a. b. c. under that paragraph doesn't render properly on 
GitHub Markdown flavor :)

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.

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

Like I said already, the current language seems to have different 
interpretations and we should clarify it. Was it ever the intent to 
include both EKU and NC in all cases of EKU? It would be a very easy 
thing to write had that been the intent from Browser members. CAs could 
easily follow. If these arguments were discussed when 7.1.5 was drafted, 
it should be in the archives.

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