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 (11)

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: 6317
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Matthew Holt
Date Reported: 2020-10-23

Section 7.5.1 says:

The server is said to "finalize" the authorization when it has
completed one of the validations.

It should say:

The server is said to "finalize" the authorization when it has
successfully completed one of the validations or failed all of
them.

Notes:

The current handling of failed challenges is ambiguous, or at least inefficient.

To get a certificate, a client creates an Order. The client then has to validate all Authorizations ("authzs"). For each Authorization, the client needs to successfully complete one of the offered Challenges. One successful Challenge is sufficient to validate the authz. However, currently in practice, one failed Challenge is sufficient to invalidate the authz, and thus the entire Order. To try another Challenge, the client then has to first deactivate the other Authorizations (expensive) and create a new Order (also expensive), then repeat the whole process, remembering what was already tried.

It is proposed that an Authorization MUST NOT be finalized until all possible challenges have failed. The client could then simply try the next Challenge. In other words, a single failed Challenge should not invalidate an authz; an authz should be "pending" until all offered challenges have failed or one has succeeded.

The spec should be clear that a single failed challenge is not sufficient to finalize an authz which has multiple possible challenges.

ACME servers see many, many failed validations. ACME clients need to keep more state. This change will speed up ACME transactions, lower costs for CAs, reduce code complexity, and make ACME more reliable on the whole.

Real-world experience: https://github.com/mholt/acmez/commit/80adb6d5e64a3d36a56c58c66965b131ea366b8c
Mailing list discussion: https://mailarchive.ietf.org/arch/msg/acme/wIHaqikTCZ59zrWsUUus8lZ4VSg/

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

Reported By: Evangelos Karatsiolis
Date Reported: 2020-12-23

Section 7.1.4 says:

   wildcard (optional, boolean):  This field MUST be present and true
      for authorizations created as a result of a newOrder request
      containing a DNS identifier with a value that was a wildcard
      domain name.  For other authorizations, it MUST be absent.
      Wildcard domain names are described in Section 7.1.3.

It should say:

   wildcard (optional, boolean):  This field MUST be present and true
      for authorizations created as a result of a newOrder request
      containing a DNS identifier with a value that was a wildcard
      domain name.  For other authorizations, it MUST be absent or
      false.  For pre-authorizations, it MUST be absent or false.
      Wildcard domain names are described in Section 7.1.3.

Notes:

This section states that the wildcard field must be absent for other authorizations, but the example in this section has an explicitly set wildcard field with value false. The proposed change allows both options, either omitting it or explicitly setting it to false. Also a sentence has been added to explicitly describe the behavior for pre-authorizations.

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.

Report New Errata