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 > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
