I think this may be a shortcoming of the RFC.
- What status should a Challenge show if the Authorization expired?
- What status should a Challenge show if the Authorization was deactivated?
- What status should a Challenge show if the Authorization was revoked?
Pebble, and IIRC Boulder, show these unusable Challenges as
pending. The only transitions are for valid or invalid, and these situations are neither.
Just to be clear, I am talking about responses when interrogating the Challenge object’s Resource URL after it has been discovered. An Authorization object could simply remove these object from the
challenges payload, but once the Client has seen the Authorization object and noted these items… well, they exist and IMHO should have a correlated status or expected server behavior.
Each ACME object type goes through a simple state machine over its lifetime. The "status" field of the object indicates which state the object is currently in. Challenge objects are created in the "pending" state. They transition to the "processing" state when the client responds to the challenge (see Section 7.5.1) and the server begins attempting to validate that the client has completed the challenge. 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. If validation is successful, the challenge moves to the "valid" state; if there is an error, the challenge moves to the "invalid" state. pending | | Receive | response V processing <-+ | | | Server retry or | | | client retry request | +----+ | | Successful | Failed validation | validation +---------+---------+ | | V V valid invalid State Transitions for Challenge Objects