Subject: [Acme] "Status" field clarification

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Mar 2018 09:04:33 -0500

Hey all,

We had a couple of GitHub issues and mailing list posts expressing
confusion about the "status" field in ACME objects.  To try to clear all of
that up, I've posted a PR that lays out required state transitions and
aligns the field descriptions with that description.  All the description
should look very familiar.  The only innovation is to introduce a "ready"
state on orders, to give clients an easy way to know when to finalize.

https://github.com/ietf-wg-acme/acme/pull/400

As you're probably aware the I-D deadline is Monday, so please send
comments ASAP.  If I don't hear anything back from this list, I'll confer
with my fellow editors and we'll make a unilateral decision for us to
discuss in London (and obviously roll back if needed).

Thanks,
--Richard

---

From: Logan Widick <[email-masked]>
Date: Fri, 2 Mar 2018 08:31:00 -0600

Are challenge retries still supported? If so, how will retries affect the
state transitions? What state would a server use to indicate that something
had an error but could be retried later?

Sincerely,

Logan Widick

On Mar 2, 2018 08:04, "Richard Barnes" <[email-masked]> wrote:

Hey all,

Thanks,
--Richard

_______________________________________________
Acme mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/acme

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Mar 2018 10:37:42 -0500

Good catch.  I think the right answer is to keep the challenge in
"processing".  We already have the following text in "Retrying Challenges"
(amended s/pending/processing/):

"""
While the server is still trying, the status of the challenge remains
“pending”; it is only marked “invalid” once the server has given up.
"""

I added some prose and tweaked the diagram to show retry events leading the
processing state back to itself:

https://github.com/ietf-wg-acme/acme/pull/400/commits/bfaf4231ffb26309f71913f3e1cb03c6e7cd0e18

Thanks,
--Richard