Does anyone have opinions on how retrying authorizations should work?
I'll work on writing it up, but it would be helpful to have early feedback.

On 09/12/2016 02:27 PM, Jacob Hoffman-Andrews wrote:
> Currently, Let's Encrypt considers each authorization a one-shot. Once a
> client POSTs to a challenge URL, the server validates the challenge and
> changes the authorization status to either "valid" or "invalid."
> Under the new-application flow, this becomes more awkward. If you
> request a certificate with 50 names on it, and successfully validate 49
> of those names, then fail the 50th, you would need to create a whole new
> application object. The server can reuse the 49 successful validations,
> but it's fairly common for a user to need to retry repeatedly. For
> instance, their server may be misconfigured in a way that is not
> immediately obvious, for instance with an over-aggressive firewall.
> In this common case, the server needs to store an application object for
> each retry. Application objects are more expensive than authorization
> objects because they contain full CSRs, which commonly contain full RSA
> keys. They also need to contain a list of associated authorization
> objects. We'd like to minimize the amount of storage required by such
> repeated retries.
> Also, I suspect that the existing infrastructure of other CAs does not
> consider an order canceled if a single validation attempt fails, which
> means the current one-shot approach is not a good match.
> I'm thinking we may need to make challenges retryable (up to some
> server-set limit). This would mean making the Error and ValidationRecord
> fields capable of representing multiple errors and multiple validation
> attempts, and potentially adding a new state to authorization objects:
> "errored, but retryable."
> Advantages:
>  - Reduces storage cost for repeated failures.
>  - Allows a client to try multiple times using the same token.
>  - Potentially better match with non-Let's Encrypt CAs' workflow.
> Disadvantages:
>  - Adds significant complexity to protocol.
> I'm interested in feedback and opinions, and possible alternate approaches.
> Thanks,
> Jacob
> _______________________________________________
> Acme mailing list

Acme mailing list

Reply via email to