[Servercert-wg] Removing the exception to allow non-critical name constraints

[Ryan Sleevi]

RFC 5280, Section 4.2.1.10, requires that the nameConstraints extension
MUST be marked critical:
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

The Baseline Requirements, v1.6.6, 7.1.2.2 (f), reduces this to a SHOULD be
marked critical:
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf#page=51 .
The following explanation is provided as rationale:

* Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10),
> however, they MAY be used until the Name Constraints extension is supported
> by Application Software Suppliers whose software is used by a substantial
> portion of Relying Parties worldwide.


This change was introduced in CA/B Forum Ballot 75,
https://cabforum.org/2012/06/08/ballot-75-nameconstraints-criticality-flag/

For those that recall the discussion, the rationale was that at the time of
adoption, versions of Apple macOS and iOS did not support the
nameConstraints extension. Similarly, OpenSSL 0.9.8 also did not support
nameConstraints. As a consequence, they treated intermediate CA
certificates with a critical nameConstraints extension as certificates with
an unhandled critical extension, and would thus fail to validate.

While this was exactly the intended behaviour of RFC 5280, it created a
chicken-and-egg problem. nameConstraints would help CAs reduce the scope of
sub-CAs, giving rise to the notion of Technically Constrained sub-CAs, but
CAs could not deploy them while complying with RFC 5280 /and/ have their
certificates work with Apple products or major OpenSSL deployments. The
exception was born to allow the certificates to be constrained for the
platforms that supported nameConstraints, while leaving them unconstrained
for platforms that did not; letting the security risk be absorbed by the
client.

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? This would
allow for testing and interoperability issues to be highlighted, along with
the overall proportion of traffic relevant to the "Application Software
Suppliers whose software is used by a substantial portion of Relying
Parties worldwide.

This would apply to issuance of subordinate CA certificates (including
"reissuance", which is still issuance).

The use of existing certificates issued under the legacy exception would
and should be phased out, in order to ensure consistent processing of
constraints. However, that could be discussed separately, since that may
involve replacing existing certificates, whether they be leaf certificates
or through replacing the subordinate CA with a "more constrained" version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191015/f6dd8d3c/attachment.html>