On 03/25/2017 09:40 AM, Hugo Landau wrote: > Currently, when an order is created, authorizations are created for it, > and challenges are created for each of those authorizations. > > If a challenge is failed once, the challenge comes to have status > "invalid", as does the authorization containing it. The order containing > the authorization becomes unfulfillable. I agree that this is an issue; You and I talked about it previously in the thread "New application flow and retries," but didn't get much feedback from the rest of the group.
Note that authz's are recyclable, so the impact is not quite so bad as you describe. But even if you just consider the CSR, each new-order is fairly expensive. A minimum of 1k of storage for a CSR with a 2048-bit RSA key. Under the current model, a client that is having validation problems and retries repeatedly will consume at least 1k of database space per try. As a result, CAs will likely need to limit new-order creations rather strictly, which makes life harder for clients. I think the way CAs traditionally handle this is as you suggest: by making challenges retryable. Note that this implies that orders typically never get invalidated, they just expire after some period of time (or error out if there's a problem during issuance, like CAA). This also implies that clients would potentially need to keep state across invocations. Specifically, clients would need to store the private keys used for extant orders, so if a subsequent run completes an order, the client is able to use the resulting certificate. What's your thought on the additional burden on clients? What is the rest of the group's thoughts on whether we'd have to restart WGLC for this? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
