[pkix] [Errata Held for Document Update] RFC5280 (5997)

[RFC Errata System <[e-mail]>]

The following errata report has been held for document update 
for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5997

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Ryan Sleevi <[e-mail]>
Date Reported: 2020-02-27
Held by: Benjamin Kaduk (IESG)

Section: 4.2.1.10

Original Text
-------------
   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.


Corrected Text
--------------
   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.

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Publication Date    : May 2008
Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG