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
