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

[Wayne Thayer]

 Thanks Ryan. This is a good idea, but I'd like to hear Apple's thoughts on
the timing. El Capitan (the version of macOS prior to Sierra) appears to
still have significant usage, even though it's not receiving security
updates.

- Wayne

On Tue, Oct 15, 2019 at 12:32 PM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191015/3e333744/attachment-0001.html>