Re: [pkix] [lamps] Fwd: [Technical Errata Reported] RFC5280 (5997)

[Russ Housley <[e-mail]>]

Ryan:

I see the point you are trying to make, but the exact substitution that you propose breaks the sentence that follows.

OLD

   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.

NEW

   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 <http://host.example.com/>, then www.host.example.com would satisfy the
   constraint but host1.example.com would not.

> On Feb 28, 2020, at 1:03 PM, Ryan Sleevi <[e-mail]> wrote:
> 
> I've heard word that this may not have gone out to the PKIX list, but I did want to pass this along with LAMPS.
> 
> As both the current syntax and semantics are ambiguous, judging by implementation behaviour, I'm totally appreciative that the suggested change might be rejected or might be held for a hypothetical document update in the future.
> 
> However, I did want to bring to broader attention and document the fact that the ambiguity has lead to different levels of guarantees. It was recently pointed out to me that Apple adopted the "URI-like" syntax, as discussed at https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html <https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html> , while as mentioned in the Errata, Go and OpenSSL seem to have adopted the "PEBKAC" syntax of assuming it's an encoding error.
> 
> Within the Web PKI, tools like Amazon's certlint treats this as an error, while tools like ZLint inherit Golang's permissiveness. As a consequence, unless the CA applies both checks (which is strongly recommended, due to certlint attempting to compile the ASN.1 modules to offer stricter validation), it's possible that such certificates might continue to proliferate. As discussed within the linked Golang issue, there's unfortunately a number of documentation examples that use the leading period example, and so RFC 5280 CAs that don't participate exclusively in the Web PKI are even more at risk of the varying interpretations.
> 
> ---------- Forwarded message ---------
> From: RFC Errata System <[e-mail] <mailto:[e-mail]>>
> Date: Thu, Feb 27, 2020 at 5:54 PM
> Subject: [Technical Errata Reported] RFC5280 (5997)
> To: <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
> Cc: <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
> 
> 
> The following errata report has been submitted 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 <https://www.rfc-editor.org/errata/eid5997>
> 
> --------------------------------------
> Type: Technical
> Reported by: Ryan Sleevi <[e-mail] <mailto:[e-mail]>>
> 
> Section: 4.2.1.10
> 
> Original Text
> -------------
> DNS name restrictions are expressed as host.example.com <http://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.  
> 
> Corrected Text
> --------------
> The syntax of dNSName MUST be as described 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.  
> 
> 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://github.com/golang/go/issues/16347>
> - https://rt.openssl.org/Ticket/Display.html?id=3562 <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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> 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
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm