RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (2)

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5983
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jason Baker
Date Reported: 2020-02-14
Verifier Name: Benjamin Kaduk
Date Verified: 2020-02-29

Section 9.1 says:

   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)

It should say:

   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-----

Errata ID: 6016
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Benjamin Wilson
Date Reported: 2020-03-13
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-13

Section 7.3.5 says:

holder of the new key to take over the account form the holder of the

It should say:

holder of the new key to take over the account from the holder of the

Notes:

Should be "from" instead of "form"

Status: Reported (9)

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5729
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Rob Stradling
Date Reported: 2019-05-22

Section 7.5.1 says:

The client indicates to the server that it is ready for the challenge
validation by sending an empty JSON body ("{}") carried in a POST
request to the challenge URL (not the authorization URL).

It should say:

The client indicates to the server that it is ready for the challenge
validation by sending a POST request to the challenge URL (not the
authorization URL), where the body of the POST request is a JWS object
whose JSON payload is a response object (see Section 8).  For all
challenge types defined in this document, the response object is the
empty JSON object ("{}").

Notes:

It's clear from other text in section 7.5.1 that the "empty JSON body" is interpreted by the ACME server as a "response object". (The first function of this erratum is to clarify this point).

Section 8 says that "The definition of a challenge type includes...Contents of response objects", and section 7.5.1 notes that "the challenges in this document do not define any response fields, but future specifications might define them". (The second function of this erratum is to permit clients to send response objects that contain response fields).

Errata ID: 5732
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Rob Stradling
Date Reported: 2019-05-23

Section 8 says:

A challenge object with an error MUST have status
equal to "invalid".

It should say:

A challenge object with an error MUST have status
equal to "processing" or "invalid".

Notes:

Section 8.2 says that 'The server MUST add an entry to the "error" field in the challenge after each failed validation query'. However, if the challenge must then become "invalid", it is never possible to retry any validation query (because "invalid" is a final state for a challenge object).
This erratum is necessary to permit validation query retries to ever happen.

Errata ID: 5861
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: owen friel
Date Reported: 2019-09-23

Section 7.4.1 says:


It should say:

If a server receives a newAuthz request for an identifier where the authorization object already exists, whether created by CA provisioning on the ACME server or by the ACME server handling a previous newAuthz request from a client, the server returns a 200 (OK) response with the existing authorization URL in the Location header field and the existing JSON authorization object in the body.

Notes:

The above text (or similar) should be appended to the end of section 7.4.1

Errata ID: 6030
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Matt Palmer
Date Reported: 2020-03-25

Section 7.2 says:

To get a fresh nonce, the client sends a HEAD request to the newNonce
resource on the server.  The server's response MUST include a Replay-
Nonce header field containing a fresh nonce and SHOULD have status
code 200 (OK).  The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

It should say:

To get a fresh nonce, the client sends a HEAD request to the newNonce
resource on the server.  The server's response MUST include a Replay-
Nonce header field containing a fresh nonce and SHOULD have status
code 204 (No Content).  The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

Notes:

RFC7321 s4.3.2, says "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET". I can't see any rationale for violating this SHOULD in the discussion in the GH issue which introduced the discrepancy in response code between GET and HEAD (https://github.com/ietf-wg-acme/acme/pull/371), thus (IMHO) it violates the tenets of a SHOULD, as "the full implications" do not appear to have "be[en] understood and carefully weighed before choosing a different course" (RFC2119, of course).

Errata ID: 6103
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Theodor Nolte
Date Reported: 2020-04-14

Section 7.1. says:

   o  A "newAccount" resource (Section 7.3)

   o  A "newOrder" resource (Section 7.4)

It should say:

   o  A "newAccount" resource (Section 7.3)

   o  A "newAuthz" resource (Section 7.4)

   o  A "newOrder" resource (Section 7.4)

Notes:

The item for the "newAuthz" resource is missing in the list of resources.

Errata ID: 5733
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rob Stradling
Date Reported: 2019-05-23

Section 8.3 says:

POST /acme/chall/prV_B7yEyA4

It should say:

POST /acme/chall/prV_B7yEyA4 HTTP/1.1

Errata ID: 5734
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rob Stradling
Date Reported: 2019-05-23

Section 8.4 says:

POST /acme/chall/Rg5dV14Gh1Q

It should say:

POST /acme/chall/Rg5dV14Gh1Q HTTP/1.1

Errata ID: 5735
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rob Stradling
Date Reported: 2019-05-23

Section 8.3 says:

GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0

It should say:

GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0 HTTP/1.1

Errata ID: 6104
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Theodor Nolte
Date Reported: 2020-04-14

Section 6.7.1 says:

   in the problem document.

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Link: <https://example.com/acme/directory>;rel="index"

{
    "type": "urn:ietf:params:acme:error:malformed",
    "detail": "Some of the identifiers requested were rejected",
    "subproblems": [
        {
            "type": "urn:ietf:params:acme:error:malformed",
            "detail": "Invalid underscore in DNS name \"_example.org\"",
            "identifier": {
                "type": "dns",
                "value": "_example.org"
            }
        },
        {
            "type": "urn:ietf:params:acme:error:rejectedIdentifier",
            "detail": "This CA will not issue for \"example.net\"",
            "identifier": {
                "type": "dns",
                "value": "example.net"
            }
        }
    ]
}

It should say:

   in the problem document.

   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Link: <https://example.com/acme/directory>;rel="index"

   {
       "type": "urn:ietf:params:acme:error:malformed",
       "detail": "Some of the identifiers requested were rejected",
       "subproblems": [
           {
               "type": "urn:ietf:params:acme:error:malformed",
               "detail": "Invalid underscore in DNS name \"_example.org\"",
               "identifier": {
                   "type": "dns",
                   "value": "_example.org"
               }
           },
           {
               "type": "urn:ietf:params:acme:error:rejectedIdentifier",
               "detail": "This CA will not issue for \"example.net\"",
               "identifier": {
                   "type": "dns",
                   "value": "example.net"
               }
           }
       ]
   }

Notes:

The code block of the HTTP reply is not aligned.

Status: Held for Document Update (1)

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5979
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: jonathan vanasco
Date Reported: 2020-02-11
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-02-24

Section 7.4 says:

 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued.


It should say:

 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued. The server returns an order URL in a Location header field.

Notes:

The RFC does not specify/require where the "order URL" is presented. The RFC is very explicit about where other URLs are obtained, and the common understanding is that the URL appears in a Location header after a new-order.

For example:

In 7.3; 7.3.1; 7.3.5, the RFC explicitly declares the account URL is in the Location header field.

In 7.4.1 the RFC is explicit that authorization URLs in pre-authorization appear in the Location header field.

But the order URL is only mentioned by example:

In 7.4, the RFC illustrates the order URL appearing in the Location header field (All clients seem to implement this). In 7.1, the RFC shows a table with "a typical sequence of requests" that note the "account" and "order" URLs appear in the location header field.

The specification should state something to the effect of "The server returns an order URL in a Location header field." making this functionality explicit.

Status: Rejected (1)

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5771
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Rob Stradling
Date Reported: 2019-07-02
Rejected by: Benjamin Kaduk
Date Rejected: 2019-07-17

Section 7.1.1 says:

Clients access the directory by sending a GET request to the
directory URL.

It should say:

Clients access the directory by sending a GET request to the directory
URL.  Before making a request to any URL from the directory, the client
MUST evaluate whether the directory object is still fresh according to
the Cache-Control header(s) received when that directory object was
accessed.  If no Cache-Control header(s) were received, the client MUST
act as if "Cache-Control: no-cache" was received.  If the directory
object is no longer fresh, the client MUST access the directory again
(by sending another GET request to the directory URL) and then use the
updated directory object.

Notes:

The original text is underspecified, because it doesn't say how long a directory remains valid. A server should be able to update its directory (e.g., to add support for newAuthz, to update the termsOfService URL, etc) without having to worry about clients holding on to stale directory objects.
Whilst in practice many clients tend to re-fetch the server's directory object frequently, I think that it's unwise to leave this to chance.
--VERIFIER NOTES--
WG consensus per the thread including https://mailarchive.ietf.org/arch/msg/acme/I2oeALKJTyCwlMOp1v9BTadahyE is to reject the proposed erratum.

Report New Errata