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

[Russ Housley <[e-mail]>]

Ben:

I would like to see the revised text put in the errata, and I think Hold for Doc Update is fine.

Russ


> On Mar 3, 2020, at 12:15 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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 <[e-mail]> 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 <[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 ,
>>> 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]>
>>> Date: Thu, Feb 27, 2020 at 5:54 PM
>>> Subject: [Technical Errata Reported] RFC5280 (5997)
>>> To: <[e-mail]>, <[e-mail]>, <
>>> [e-mail]>, <[e-mail]>, <
>>> [e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>,
>>> <[e-mail]>, <[e-mail]>
>>> Cc: <[e-mail]>, <[e-mail]>, <[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
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Ryan Sleevi <[e-mail]>
>>> 
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spasm
>>> 
>>> 
>>> 
> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm