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

That does seem like the right higher-order question, but it seems (to me)
fairly inevitable that this errata report must be classified as "hold for
document update" to give the WG a chance to make a definitive decision, as
the original intent remains unclear.

-Ben

On Fri, Feb 28, 2020 at 01:52:07PM -0500, Ryan Sleevi wrote:
> Thanks. You're absolutely right, that was an oversight on my part.
> 
> I think the higher-order question is what the syntax is "meant" to be, as
> the use of an illustrative example alone has lead to confusion. Even if a
> future revision retroactively 'blesses' ".example.com" as an ambiguity
> within 5280, the semantics of that are also ambiguous.
> 
> On Fri, Feb 28, 2020 at 1:39 PM Russ Housley <[email protected]> wrote:
> 
> > 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, 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 <[email protected]> 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 ,
> > 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 <[email protected]>
> > Date: Thu, Feb 27, 2020 at 5:54 PM
> > Subject: [Technical Errata Reported] RFC5280 (5997)
> > To: <[email protected]>, <[email protected]>, <
> > [email protected]>, <[email protected]>, <
> > [email protected]>, <[email protected]>, <[email protected]>, <[email protected]>,
> > <[email protected]>, <[email protected]>
> > Cc: <[email protected]>, <[email protected]>, <[email protected]>
> >
> >
> > 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
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Ryan Sleevi <[email protected]>
> >
> > 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.
> >
> > 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://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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/spasm
> >
> >
> >

> _______________________________________________
> Spasm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/spasm