Re: [Acme] [Technical Errata Reported] RFC8555 (5983)

Richard Barnes <rlb@ipv.sx> Tue, 25 February 2020 13:05 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266BB3A0C26 for <acme@ietfa.amsl.com>; Tue, 25 Feb 2020 05:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 oHy590kN1rVi for <acme@ietfa.amsl.com>; Tue, 25 Feb 2020 05:05:04 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 3A0D83A0C22 for <acme@ietf.org>; Tue, 25 Feb 2020 05:05:03 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id 11so7720328qkd.1 for <acme@ietf.org>; Tue, 25 Feb 2020 05:05:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4KBm40AiMugWzSW7Cx0bYn8szKP3EBwzxc2I21nxMeA=; b=gJ4grSS5D8EBxetmVgH1g//ZrM5FtGPlJXGh11cRTRutxqU6CfbIkYEDu4RTLEa5zW mbCFZeanzt2CqwHkKr//md+b1ycR396GyqSQ4+NYMet9Wm312pdow2BBnz4WmCdW8DXE rLNLHhS2EHjIUeeh57xCEVz6w4412xOJXhxmLmwCUb9+mVukmpVWPNpJ8xZ5n261C3bp KZpQktVoYVcv4fWqeRewqfDumkRt5eB9+9UJv0yGzDQhikl3Yh+UIXnCymZ2stpDTLbB qypRURW2YgtjuFGhoB1VPDRC95KjCkuaLxs68kUfB66WUsa2Nc2gKRCNhs0+zb5dGgxL FbGg==
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=4KBm40AiMugWzSW7Cx0bYn8szKP3EBwzxc2I21nxMeA=; b=W6k/FKMsuD0+K2ajWjPWUpFnDTrgYTD5G95/dJPZOUQ8v8vUzbooYNpCuNdyRDI7dm 1Mm3z7e2cVNrLAU55ZiSYl9372OEukX5KRN10UiDt768FCv3eXhklLqny3FKD0JE/QFa V2wXuLa8AEqL+c48bXsN2pb/c+IqCIhR779XLuQvHj0Vf1qB4pfdgAysqaO2/VqyP0jx U5ir0OZU8Y5f+f2lXVYT8FjdUYC8ZsKxPCTjxIDJMl/LwypfiYcbAveKkzW7toLdTfvc yJLsolGk/nHRZtmFlNZi6TZ1eBrAmOhRiPwBGpTvWmGAvgd+rk8I1OUmBl5iMhuSmDip YuYw==
X-Gm-Message-State: APjAAAXtFBJYNgEzIh4iO9ts1L5580gbzvnTn0slrRvhvjCgmeyNecxs FLRXZJQMQGIS1oDCMWDDeg7/qs/cXVvajABHRzb4eg==
X-Google-Smtp-Source: APXvYqwhlGlrr+Kj2r6wrk8XfWmcpmVDUOaqOWq6aAvoZycgclgjNfg3iNbBDBu8ue0/bF3wVJr6dwL+PjVnxhLHkgY=
X-Received: by 2002:a05:620a:989:: with SMTP id x9mr56731666qkx.371.1582635902598; Tue, 25 Feb 2020 05:05:02 -0800 (PST)
MIME-Version: 1.0
References: <20200214181853.537B6F40709@rfc-editor.org> <20200225014621.GD5814@kduck.mit.edu>
In-Reply-To: <20200225014621.GD5814@kduck.mit.edu>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 25 Feb 2020 08:04:47 -0500
Message-ID: <CAL02cgQHhHn-7wju28a8Lt=yihYy4-Hz8UZPgg0oyy0vgYgYnQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Jacob Hoffman-Andrews <jsha@eff.org>, Daniel McCarney <cpu@letsencrypt.org>, James Kasten <jdkasten@umich.edu>, Roman Danyliw <rdd@cert.org>, "Salz, Rich" <rsalz@akamai.com>, Yoav Nir <ynir.ietf@gmail.com>, thebaker@google.com, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c891f2059f6622c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/qfEIm0QA8JVXGq0hAprHYxJePf8>
X-Mailman-Approved-At: Tue, 25 Feb 2020 08:06:47 -0800
Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (5983)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2020 13:05:07 -0000

This seems Verified to me.

On Mon, Feb 24, 2020 at 8:46 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Authors, should this be marked Verified?
>
> Thanks,
>
> Ben
>
> On Fri, Feb 14, 2020 at 10:18:53AM -0800, RFC Errata System wrote:
> > The following errata report has been submitted for RFC8555,
> > "Automatic Certificate Management Environment (ACME)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5983
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Jason Baker <thebaker@google.com>
> >
> > Section: 9.1
> >
> > Original Text
> > -------------
> >    A file of this type contains one or more certificates encoded with
> >    the PEM textual encoding, according to [RFC7468].  The textual
> >    encoding of certificates in this file MUST use the strict encoding
> >    and MUST NOT include explanatory text.  The ABNF for this format is
> >    as follows, where "stricttextualmsg" and "eol" are as defined in
> >    Section 3 of RFC 7468:
> >
> >    certchain = stricttextualmsg *(eol stricttextualmsg)
> >
> > Corrected Text
> > --------------
> >    A file of this type contains one or more certificates encoded with
> >    the PEM textual encoding, according to [RFC7468].  The textual
> >    encoding of certificates in this file MUST use the strict encoding
> >    and MUST NOT include explanatory text.  The ABNF for this format is
> >    as follows, where "stricttextualmsg" is as defined in
> >    Section 3 of RFC 7468:
> >
> >    certchain = stricttextualmsg *(stricttextualmsg)
> >
> > Notes
> > -----
> > Examples within RFC 8555 indicate that only one EOL should be present
> between entries in the PEM chain.
> >
> > RFC 7468 already defines a stricttextualmsg as ending with EOL
> > stricttextualmsg = preeb eol
> >                            strictbase64text
> >                            posteb eol
> >
> > If a second EOL is to be added before each strict textual message this
> would result in a blank line between entries.  The prior example in
> https://tools.ietf.org/html/rfc8555#section-7.4.2 indicates an intention
> for only one EOL marker to be used:
> >    -----BEGIN CERTIFICATE-----
> >    [End-entity certificate contents]
> >    -----END CERTIFICATE-----
> >    -----BEGIN CERTIFICATE-----
> >    [Issuer certificate contents]
> >    -----END CERTIFICATE-----
> >    -----BEGIN CERTIFICATE-----
> >    [Other certificate contents]
> >    -----END CERTIFICATE-----
> >
> > 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.
> >
> > --------------------------------------
> > RFC8555 (draft-ietf-acme-acme-18)
> > --------------------------------------
> > Title               : Automatic Certificate Management Environment (ACME)
> > Publication Date    : March 2019
> > Author(s)           : R. Barnes, J. Hoffman-Andrews, D. McCarney, J.
> Kasten
> > Category            : PROPOSED STANDARD
> > Source              : Automated Certificate Management Environment
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
>