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

Ryan Sleevi <ryan-ietf@sleevi.com> Fri, 28 February 2020 18:52 UTC

Return-Path: <ryan.sleevi@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CBB3A0043; Fri, 28 Feb 2020 10:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whVB5nkpT78f; Fri, 28 Feb 2020 10:52:21 -0800 (PST)
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF46D3A00B0; Fri, 28 Feb 2020 10:52:20 -0800 (PST)
Received: by mail-ed1-f53.google.com with SMTP id c26so4515041eds.8; Fri, 28 Feb 2020 10:52:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MSNSRKjoyzTGtYvz6dR00ka9cPyfK0J09Wis2MJ9kWs=; b=CLdp+RPNnOVC1+HwhIdaQ2XBb0Dofhp8CxTN/4L5cfVfaydzP+zmXMu2fdRgOiOK5D 9WbQlqgOSxVGUnA3Pg7suofdBZ4djke3LmEvPnClNRAGzK03wsSvqQX4b8OMYXDeXZMw 6CArSU68YcgFLngtt9CDBr+pNjmZpunluracPJnVKelq2maiduQWYeR2oNeNqOzNZXkC 4ARmOKl+BZ7ZYvCNarqWNIXx6OuSxE4zRrDeuqkSR2aT2dz9m6FPEhhd/2Yby73ZWfKE ynDlzK5g3PdwRwVGQAUMEwJgfp3n92YQqOo6j6sFK0sSfiZWyOnaH2aK4JS33QIFmc6n PhuQ==
X-Gm-Message-State: APjAAAXxXyu1F1wwiQnBk7Dc15kdf24ROBi59EGn213CW5MfeHqucTrL kifHVjHakDw3BCFFsCcVY9rSiCsR
X-Google-Smtp-Source: APXvYqwQACk205jC2PjdFHqq1VF6wrllY+HeGNlJSmVii5WT1565HQfPkGBjcGCaj7JmObmtPI/K7A==
X-Received: by 2002:a17:906:6d03:: with SMTP id m3mr5148247ejr.39.1582915938737; Fri, 28 Feb 2020 10:52:18 -0800 (PST)
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id l9sm115234ejg.42.2020.02.28.10.52.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 10:52:18 -0800 (PST)
Received: by mail-wm1-f54.google.com with SMTP id m3so4383648wmi.0; Fri, 28 Feb 2020 10:52:18 -0800 (PST)
X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr5831973wme.125.1582915937880; Fri, 28 Feb 2020 10:52:17 -0800 (PST)
MIME-Version: 1.0
References: <20200227225404.CA7ADF40714@rfc-editor.org> <CAErg=HEUhTvuhxEv91C8GQZd01XiPByfaqjcvRmgJ00+C2QNRw@mail.gmail.com> <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com>
In-Reply-To: <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Fri, 28 Feb 2020 13:52:07 -0500
X-Gmail-Original-Message-ID: <CAErg=HEAPkYXudf_p9oES5yh+T-5_DxpViuw-JCpeqx-8fNKOw@mail.gmail.com>
Message-ID: <CAErg=HEAPkYXudf_p9oES5yh+T-5_DxpViuw-JCpeqx-8fNKOw@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: SPASM <spasm@ietf.org>, IETF PKIX <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002fcf12059fa75634"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/wA9J737yToYjVCOzGYWzt6XRepU>
Subject: Re: [pkix] [lamps] Fwd: [Technical Errata Reported] RFC5280 (5997)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 18:52:25 -0000

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 <housley@vigilsec.com> 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 <ryan-ietf@sleevi.com> 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 <rfc-editor@rfc-editor.org>
> Date: Thu, Feb 27, 2020 at 5:54 PM
> Subject: [Technical Errata Reported] RFC5280 (5997)
> To: <david.cooper@nist.gov>ov>, <stefans@microsoft.com>om>, <
> stephen.farrell@cs.tcd.ie>gt;, <sharon.boeyen@entrust.com>om>, <
> housley@vigilsec.com>gt;, <wpolk@nist.gov>ov>, <rdd@cert.org>rg>, <kaduk@mit.edu>du>,
> <kent@bbn.com>om>, <stefan@aaa-sec.com>
> Cc: <ryan-pkix@sleevi.com>om>, <pkix@ietf.org>rg>, <rfc-editor@rfc-editor.org>
>
>
> 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 <ryan-pkix@sleevi.com>
>
> 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
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>
>