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

--------------------------------------
Type: Technical
Reported by: Matthew Holt <m...@lightcodelabs.com>

Section: 7.5.1

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

Corrected Text
--------------
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/

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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to