RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549

Errata ID: 5997
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Sleevi
Date Reported: 2020-02-27
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-03-17

Section 4.2.1.10 says:

   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not.

It should say:

   For DNS names, restrictions MUST use the dNSName syntax in
   Section 4.2.1.6.  Any DNS name that can be constructed by simply
   adding zero or more labels to the left-hand side of the name satisfies
   the name constraint.  For example, if the constraint contains
   host.example.com, then www.host.example.com would satisfy the
   constraint but host1.example.com would not.

Notes:

Currently, the syntax for a dNSName nameConstraint is left implicit, and thus has resulted in ambiguities in encoding and processing that have resulted in ineroperability issues.

One interpretation is that the dNSName nameConstraint must be a valid "host name" (as discussed in RFC 8499), which is to say must be a Fully-Qualified Domain Name in the preferred name syntax. This interpretation is supported by Section 4.2.1.6, which explicitly states that for the subjectAltName. As 4.2.1.10 does not define an exception to this (as discussed in Appendix B), the interpretation, along with the existing example, would conclude that this field uses preferred name syntax, and that "DNS name" here matches the "host name" interpretation from RFC 8499

A different interpretation is that the dNSName nameConstraint uses the modified syntax similar to the URI nameConstraint. That is, it explicitly permits a leading period to indicate that one or more labels preceding is required in order to satisfy the constraint. This allows subdomains, but does not allow the base domain to match. While the language for the DNS name constraint makes it clear that a host name with no preceding period matches both that host and sub-domains, the existence of a preceding period would constraint it to only subdomains.

Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as the preferred name syntax does not permit leading periods. Alternatively, if the latter interpretation is intended, this section would benefit from making that explicit.

This has been a source of interoperability issues, with additional information and discussion captured at:
- https://github.com/golang/go/issues/16347
- https://rt.openssl.org/Ticket/Display.html?id=3562

While "running code" has aligned in being permissive with a leading period, implementations have gone and seemingly aligned on a third interpretation:

The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the exception that it MAY contain a leading period. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name, ignoring any leading period, satisfies the name constraint.

This seems to support implementations expecting the first interpretation in the certificates they receive, and seeing leading period as an encoding mistake, not an explicit desire for the second interpretation.

Report New Errata