I agree. On Tue, Feb 25, 2020, 5:05 AM Richard Barnes <[email protected]> wrote:
> 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
