Challenge status

[jvanasco]

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.

Section 7.1.6

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