Re: [Acme] Retrying challenges - spec bug?

[Rob Stradling <[e-mail]>]

I've filed an erratum for this as well:
http://www.rfc-editor.org/errata/eid5732

On 20/05/2019 13:56, Rob Stradling wrote:
> https://tools.ietf.org/html/rfc8555#section-8.2 says:
>     'The server MUST add an entry to the "error" field in the challenge
>      after each failed validation query.'
> 
> And https://tools.ietf.org/html/rfc8555#section-8 says:
>     'A challenge object with an error MUST have status equal to
>      "invalid".'
> 
> The state transition diagram for challenge objects
> (https://tools.ietf.org/html/rfc8555#section-7.1.6) appears to
> indicate(*) that "invalid" is a final state for a challenge object,
> meaning that it is no longer possible for it to transition to "valid"
> and that retrying the challenge would therefore be pointless.
> 
> ISTM that the "error" field could be a very useful feedback mechanism
> inbetween retries, and that a challenge should only go to the "invalid"
> state once the ACME server has stopped retrying validation queries for
> that challenge.  Is this what the authors intended?
> 
> Do folks agree that 'A challenge object with an error MUST have status
> equal to "invalid"' is a bug in the spec?
> 
> 
> (*) I wonder if I'm reading the state transition diagrams correctly...
> In section 7.1.6, the state transition diagram for authorization objects
> shows that "invalid" is a final state...right?  But if that's the case,
> why does this sentence not list "invalid" as a final state?
> 
>     'The order also moves to the "invalid" state if it expires or one of
>      its authorizations enters a final state other than "valid"
>      ("expired", "revoked", or "deactivated").'
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited