On 03/15/2018 10:03 AM, Hugo Landau wrote: > It suggests that a challenge should be retried automatically by the server, > and > that the challenge should remain in the "processing" state for this time. It > also states that the "invalid" state should be used after the server has given > up. It also states that the client should be explicitly able to request > retries.
I think the idea here is that there's a window of time during which the challenge is in "processing" state. During that time, the server can choose to retry on some interval, and also the client can ask for early retries (so a client who is trying different things. So long as the server is willing to keep trying, it wouldn't transition into "invalid" state. This is discussed a bit more in the recently added "Status Changes" section: https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.6. "Note that within the “processing” state, the server may attempt to validate the challenge multiple times (see Section 8.2). Likewise, client requests for retries do not cause a state change." > This doesn't make sense. The implication is that "invalid" is a final state, > and the challenge cannot move back to "processing" after becoming "invalid". > If > a server doesn't wish to make automatic retries, it has "given up" and the > specification thus dictates that the challenge move to "invalid", but this > makes it impossible to retry the challenge. This precludes an implementation > where the server e.g. only makes retries at the request of the client. For a > server which does make retries automatically, it also means the client's > ability to request retries ends when the server ceases to make retries > automatically, even though this is largely an internal detail of the server > and > not really an exposed aspect of the API. I understand this reading, although that's not the intent. A server that wanted to offer retries only upon client initiation would simply leave the challenge in "processing" state until the challenge's authorization expired. Essentially, the server would never "give up" until expiration time. > The specification doesn't say anything > about whether a challenge becoming permanently "invalid" precludes attempting > another challenge in the same authorization. I think the intent of the spec is for this to be "server's choice." Let's Encrypt treats failing any challenge as failing the whole authorization, but in theory a different CA could do it differently. > Retries were added in the first place because the aggregation of multiple > authorizations into orders means quite a lot of progress in the issuance > process may be lost by a single challenge failure. I have to admit, even though I asked for retries to be added because I was worried about this scenario, we have not actually implemented retries at Let's Encrypt. Partly we reduced the resource consumption of orders by moving CSR submission to the last step, and partly we realized we can mitigate this problem by reusing authorizations (both pending and valid) for subsequent orders. Basically, I see that there's some possible refinement here, but I don't think it will be resolved without someone implementing retries, and I don't think we should delay finalization of the RFC to try and nail it down. There will definitely be some corners that will be worked out as deployment widens, and if necessary we can address those with errata and a follow-on spec. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
