RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Reported (6)

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

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