The specification as it stands seems to be a bit vague on the subject of challenge retries.
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. 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. The language around how processing/invalid challenges interact with authorizations is also unclear to me. The specification doesn't say anything about whether a challenge becoming permanently "invalid" precludes attempting another challenge in the same authorization. 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. But there still seem to be issues with the specification as currently written: an authorization which becomes "invalid" does so permanently and thus scuppers the entire order, which may have a hundred authorizations. IMO, challenges and authorizations should be evergreen, barring exceptional events like administrative intervention. It would make more sense for challenges to revert to "pending" when the server has given up. The attempts are still recorded as challenge errors. The "invalid" state would only be used administratively or if it is determined (for some reason) that completion of the challenge is permanently impossible (no such cases arise in the current HTTP/DNS challenges). Separately, it's unclear what happens to an authorization when a challenge becomes "invalid": >If there is an error while the authorization is still pending, then the >authorization transitions to the "invalid" state. The meaning of "an error" here is unclear. Is the intention here that a challenge becoming "invalid" precludes attempting any other challenge in that authorization? This seems like a bad idea and will result in the creation of excessive duplicate orders/authorizations. I'd argue an authorization should become invalid iff all of its challenges become invalid. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
