RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 20 records.

Status: Verified (11)

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

Source of RFC: acme (sec)

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

Reported By: Rob Stradling
Date Reported: 2019-05-22
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

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

Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Paul Wouters
Date Verified: 2024-02-22

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

Reported By: Evangelos Karatsiolis
Date Reported: 2020-12-23
Verifier Name: Deb Cooley
Date Verified: 2024-03-22

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

Reported By: Paul Breed
Date Reported: 2023-07-13
Verifier Name: Roman Danyliw
Date Verified: 2024-01-11

Section 8.1 says:

 The "Thumbprint" step indicates the computation specified in
   [RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
   [RFC7518] any prepended zero octets in the fields of a JWK object
   MUST be stripped before doing the computation.

It should say:

The "Thumbprint" step indicates the computation specified in
   [RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
   [RFC7518] any additional prepended zero octets in the fields of a JWK object
   MUST be stripped before doing the computation.  
   Fixed length fields such as found in ECDSA keys should be their natural length and 
   leading zero octets should not be stripped.

Notes:

This comment was really aimed at the leading 0 octet sometimes used with RSA, but the comment is not RSA specific. ECDSA keys can have fixed length fields (X,Y) where there can be leading zeros. This led me astray in implementing an ECDSA thumbprint routine for ACME. The result was that 1/128 ECDSA keys failed to generate t humbp[rint as leading zeros were removed.

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

Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 8.3 says:

POST /acme/chall/prV_B7yEyA4

It should say:

POST /acme/chall/prV_B7yEyA4 HTTP/1.1

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

Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 8.4 says:

POST /acme/chall/Rg5dV14Gh1Q

It should say:

POST /acme/chall/Rg5dV14Gh1Q HTTP/1.1

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

Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

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

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

Reported By: Theodor Nolte
Date Reported: 2020-04-14
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

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: 6104
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Theodor Nolte
Date Reported: 2020-04-14
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

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 indenting of the code block of the HTTP reply is not aligned.

Status: Reported (2)

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

Source of RFC: acme (sec)

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

Reported By: Rob Stradling
Date Reported: 2024-02-28

Section 8.2 says:

The server MUST provide information about its retry state to the 
client via the "error" field in the challenge and the Retry-After 
HTTP header field in response to requests to the challenge resource.

It should say:

In responding to requests to the challenge resource while the status 
of the challenge remains "processing", the server MUST provide 
information about its retry state to the client via the "error" field 
in the challenge and the Retry-After HTTP header field.

Notes:

The current text seems to require the server to include the "error" field and Retry-After HTTP header in all responses to requests for a challenge resource, even before that challenge has moved from "pending" to "processing", and even after that challenge has moved from "processing" to "valid" or "invalid". However, the "State Transitions for Challenge Objects" diagram in Section 7.1.6 shows that it only makes sense for the server to communicate "its retry state" to the client when the challenge is "processing".

I've modelled the structure of my suggested Corrected Text on similar language in Section 7.5.1: "In responding to poll requests while the validation is still in progress, the server MUST...".

Status: Held for Document Update (6)

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.

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

Reported By: Matt Palmer
Date Reported: 2020-03-25
Held for Document Update by: Deb Cooley
Date Held: 2024-03-22

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: 6317
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Matthew Holt
Date Reported: 2020-10-23
Held for Document Update by: Roman Danyliw
Date Held: 2024-01-11

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: 6843
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: James Kasten
Date Reported: 2022-02-08
Held for Document Update by: Roman Danyliw
Date Held: 2024-01-11

Section 8.3 says:

Because many web servers
allocate a default HTTPS virtual host to a particular low-privilege
tenant user in a subtle and non-intuitive manner, the challenge must
be completed over HTTP, not HTTPS.

It should say:

Because many web servers
allocate a default HTTPS virtual host to a particular low-privilege
tenant user in a subtle and non-intuitive manner, the challenge must
be initiated over HTTP, not HTTPS.

Notes:

Completing the entire http-01 challenge over HTTP is unnecessary. The threat of default HTTPS virtual hosts is remediated by "initiating" the http-01 challenge over HTTP. Validation servers which redirect from HTTP to HTTPS should be permitted following the rest of the guidance within Section 10, Security Considerations.

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

Reported By: Lloyd Wood
Date Reported: 2022-05-02
Held for Document Update by: Deb Cooley
Date Held: 2024-03-22

Throughout the document, when it says:

token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy.

It should say:

token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy, which in the 
      base64url alphabet means a minimum string length of 22 characters if the full
      scope of the base64url alphabet is in use in the token, by:
                        log2(64^22) = 132 bits of entropy


Notes:

This standards-track document doesn't specify the string ramifications for entropy; I'd expect it to be called out to implementers, just the once, and then referred to later at other tokens.

If entropy is log2 the number of possible characters (64 if full base64url set of chars is in use) then
log2 (64^21) = 126
log2 (64^22) = 132

so a minimum of 22 characters are needed to get a minimum of 128 bits of entropy in the token.

But, if the random value is specified using a subset of the base64url, say because the implementer doesn't like or use CAPITALS or (most likely) the punctuation symbols, then the token must necessarily be longer to meet the local implementer entropy requirement (though just losing only the punctuation marks means you're still good and meet the requirement with 22 characters). Not sure that matters so much on the wire.

I also have editing nits about base64url being defined clearly in ABNF just for Replay-Nonce:, but then both 'base64 alphabet' and 'base64url alphabet' are in use in the document, and base64url references are to RFC4648 via RFC7515, but those are to Base64url, not to base64url... it all seems a bit inconsistent editingwise. So all the references to 'base64 alphabet' should be to 'base64url alphabet' as defined in the doc, but it should really be 'Base64url alphabet' to be consistent with references?

(I really think that it should have been called 'Base-64_url alphabet' way back when to enphasise the punctuation use, but that ship has sailed.)

To me, 'base64 alphabet' is the a-zA-Z subset of base64... I think the document could be much clearer in this regard, and I hope any doc revisions taking into account all the other errata raised consider this too.

My thanks to Lee Maguire for pointing much of this out.

Errata ID: 6276
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: James Manger
Date Reported: 2020-09-03
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-09-04

Section 2 says:

   o  The CA verifies that the client controls the requested domain
      name(s) by having the ACME client perform some action(s) that can
      only be done with control of the domain name(s).  For example, the
      CA might require a client requesting example.com to provision a
      DNS record under example.com or an HTTP resource under
      http://example.com.

It should say:

   o  The CA verifies that the client controls the requested domain
      name(s) by having the ACME client perform some action(s) that can
      only be done with control of the domain name(s).  For example, the
      CA might require a client requesting example.org to provision a
      DNS record under example.org or an HTTP resource under
      http://example.org.

Notes:

The spec consistently uses example.com for an ACME CA server, and example.org for a site requesting a certificate -- except in this sentence.

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



Advanced Search