> 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? I don't think the additional burden is a problem.
> What is the rest of the group's thoughts on whether we'd have to restart > WGLC for this? I'd hope that if the 'can retry individual challenges' option is chosen this is considered a minor enough change to avoid restarting WGLC. However, it also seems pointless to finalize the ACME specification as an RFC when we have the opportunity to wait until Let's Encrypt obtains operational experience in production with the revised specification. It's a little bizarre that a version of the specification that isn't going to be standardized as an RFC has a lot more deployment experience attached to it than a substantially different version with no current deployment experience. It would be a different story if this WG thought it was holding anything up by virtue of deferring standarization; if another WG was waiting on an RFC to cite, or so on. But the evidence is that the fact that ACME is still an I-D hasn't stopped real-world deployment of either CAs (Let's Encrypt) or a multitude of clients. In that regard, even though I can usually be as weary as anyone at how long it can take standards organizations to finalize things (C++ concepts comes to mind), in this case, I think it would make sense to postpone finalization of the ACME specification until such time as Let's Encrypt moves the new specification into production (or, alternatively, until another CA enters on the scene and implements ACME, and gains experience with it). I'm not sure what position this WG would take on tying a neutral standards process to the implementation timeline of a particular organization; potentially it is objectionable. At the same time, the fact that ACME has been field-tested before finalization has been valuable. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
