BRs: Make nameConstraints critical

[sleevi]

This was originally raised on the servercert-wg mailing list on 2019-10-15

The BRs provide an RFC 5280 exception to allow nameConstraints to be non-critical, despite the security issues this presents. At the time the existing language was drafted, at least one major browser vendor (Apple) did not yet support nameConstraints, and a still-supported major version of OpenSSL (0.9.8) did not. Although non-critical nameConstraints expose such clients to security risk (because they will not reject a constrained certificate), at the time, it was seen as an acceptable trade-off as part of allowing CAs to more widely constrain sub-CAs, which a majority of clients would respect.

As covered in the thread, Apple has supported nameConstraints for 6 years now, and OpenSSL 0.9.8 is no longer actively maintained, so the justification for non-critical nameConstraints, as it applies to widely used software, is no longer applicable.

From the original thread, the timeline of deprecating non-critical nameConstraints identified 2022 as a workable target. As part of the certificate profiles work, the validation working group is exploring adding this sunset timeline as part of the proposed base profile.

[sleevi]

New discussion thread related to this issue.

[defacto64]

Hi Ryan,
apart from old OpenSSL and old Apple platforms, are you aware of any other widely used runtimes that may still have problems with critical nameConstraints? E.g. Java, .NET/mono, Node.js, Golang, etc.?

[sleevi]

Where “has problems” is the correct and intended behavior of “rejects the certificate”?

No, nothing that is objectively widely used. There is always the risk of bespoke embedded device scenarios, but those are largely irrelevant, as the option for the Subscriber is simply to not use a TCSC.

[defacto64]

Thank you.

[clintwilson]

I believe this can be implemented in the TBRs at this point.

[barrini]

Nice to have info about technically constrained, how affect other applications (e.g., java) and how the change to critical may affect the webPKI.
Also, .NET, go and java script may also be affected with this change.
Clint will manage this issue.

[barrini]

https://search.censys.io/search?resource=certificates&sort=RELEVANCE&per_page=25&virtual_hosts=EXCLUDE&q=parsed.extensions.name_constraints.critical%3A+true+and+validation.microsoft.has_trusted_path%3A+true can help.

[XolphinMartijn]

Expanded query with a few more trust stores:
https://search.censys.io/search?resource=certificates&q=parsed.extensions.name_constraints.critical%3A+true+and+%28validation.microsoft.has_trusted_path%3A+true+OR+validation.nss.has_trusted_path%3A+true+OR+validation.apple.has_trusted_path%3A+true+OR+validation.chrome.has_trusted_path%3Atrue%29

[tadahik]

FYI: SECOM have two name constrained intermediate with critical, and they are for our own test environment.
We are using nameConstraints to reduce the impact of mis issuance in the test environment.

[defacto64]

When it was proposed, lately, to make the criticality of the NameConstraints extension mandatory, I thought I had read somewhere that some platforms did not handle it correctly. I then managed to find the sources where I had read such information: one is the OpenSSL CookBook by Ivan Ristic [1] which warns...

In practice, name constraints are not entirely practical, because some major platforms don’t currently recognize the nameConstraints extension. If you mark this extension as critical, such platforms will reject your certificates.

I contacted Ristic for clarification, but he couldn't tell me much, other than that he was referring to Apple's platforms. A subsequent search took me to a blog by Ryan Hurst which confirms the problem on Apple platforms, but the relevant post [2] is a bit old and I am sure, even if I haven't performed a test yet, that to date both iOS and macOS support the NameConstraints extension perfectly, whether critical or not.... or not?

[1] https://www.feistyduck.com/library/openssl-cookbook/online/openssl-command-line/private-ca-creating-root.html
[2] https://unmitigatedrisk.com/?p=24

[clintwilson]

Correct, and specifically the link in the Issue description (https://archive.cabforum.org/pipermail/servercert-wg/2019-October/001196.html) provides a more detailed answer to the question:

Apple implemented nameConstraints support in iOS 9, released September
2015, and macOS 12 (Sierra), released September 2016. OpenSSL support was
introduced in the 1.0.0 release in Mar-2010; however, the 0.9.8 branch did
not reach "End of Life" until 31 Dec 2015.
As a consequence, I believe that the criteria that must be met for the MAY
are likely no longer true.
How do people feel about removing this exception in April 2020?

4 years later, nothing in this statement has changed; we're just 4 more years past when this change could have gone into effect with minimal impact.

[defacto64]

Thanks for the feedback, Clint. In the meantime I did some tests on iOS and macOS (recent versions) and there seems to be no doubt that both support a critical NameConstraints.

I did a series of further tests in other environments and I found no problems with JRE/JDK, .NET/Mono, NodeJS, Python3 and other widely used frameworks and languages.

However, to my surprise, I also found that Go (latest version 1.22.3) apparently does not recognize the NameConstraints extension and therefore, if it is critical, the TLS connection fails. I could have made some mistake, but this is what I get if I try to open a connection with (for example) https://www.pist.tn whose certificate is issued by an ICA that has a critical NameConstraints:

Error sending request: Get "https://www.pist.tn": tls: failed to verify certificate: x509: unhandled critical extension

This is the Go code I have been using to open an HTTPS connection:

res, err := http.Get(url)
if err != nil {
    log.Fatal(err)
}

[robstradling]

@defacto64 I suspect this is due to golang/go#15196 and the still-unmerged PR at golang/go#39639.

It's been over 9 years since @vanbroup's original patch set (https://go-review.googlesource.com/c/go/+/3230, created January 2015), so I'm not optimistic that this will be resolved any time soon. :-(

[defacto64]

I see, interesting.

Since this has been the situation for so long, perhaps we shouldn't worry about it too much...apparently, the said Go problem hasn't caused too much trouble to anyone, or it would have been solved by now....however I am a bit suprised that a programming language created by Google is still affected by this kind of limitation to date.

[robstradling]

apparently, the said Go problem hasn't caused too much trouble to anyone, or it would have been solved by now

AIUI, this Go problem is only triggered by Critical Name Constraints, and I'm guessing that most of the people who would be affected by this problem are currently using Non-critical Name Constraints (or no Name Constraints at all).

If Non-critical Name Constraints become prohibited, and if that means that more CAs start to use Critical Name Constraints, then I'd expect to see more people encountering this Go problem. This might then disincentivize CAs from using Name Constraints at all! However, I suppose it might also result in the Go team raising the priority of fixing this problem.