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 >
- [Acme] [Technical Errata Reported] RFC8555 (5983) RFC Errata System
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Benjamin Kaduk
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Richard Barnes
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… James Kasten