RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008Source of RFC: pkix (sec)
Errata ID: 5997
Status: Held for Document Update
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 220.127.116.11 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 18.104.22.168. 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.
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 22.214.171.124, which explicitly states that for the subjectAltName. As 126.96.36.199 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 188.8.131.52 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:
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 184.108.40.206, 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.