This seems Verified to me. On Mon, Feb 24, 2020 at 8:46 PM Benjamin Kaduk <[email protected]> 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 <[email protected]> > > > > 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
