On Thu, Aug 25, 2016 at 5:41 PM, Andrew Ayer <[email protected]> wrote:
> On Thu, 25 Aug 2016 13:57:25 -0400 > Daniel McCarney <[email protected]> wrote: > > > In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems > > to agree > > that there should be only one issuance method to simplify client > > behaviours, though he favours proactive issuance instead of > > on-finalization issuance. While > > it saves a round-trip message I'm not sure that this alone is > > convincing enough > > to choose proactive issuance as the one issuance method. > > There's another reason I prefer proactive issuance: I think the server > should automatically issue a new certificate if an application's > current certificate is about to expire and its authorizations are still > valid. This lets you create an application from a central > location with access to your account key, and then have your TLS > frontends/load balancers make unauthenticated GETs to keep the > certificate up-to-date. I think this is essential to make short-lived > certificates work robustly, but it's useful even with longer-lived > certificates. I went into further detail in my previous email[1]. > One issue that was briefly discussed at the meeting is whether the Application object should have a "certificates" array member instead of a "certificate" string member. That would allow this sort of re-issuance without erasing the old URL. Andrew: Is that something you think we need? Requiring an explicit action to issue would mean you'd need some > process somewhere to request issuance when a cert is about > to expire. This process would need access to your account key (so it > should not run on your frontend servers), and if it fails your > certificates stop renewing. > > I understand the bulk issuance use case you describe. Could it be > accomplished instead by a boolean field in the application to > enable/disable the application? Certificates would only be issued when > the application is enabled. Bulk issuers could pre-create > authorizations in the disabled state, and enable them when ready to > issue. > I was actually thinking that Daniel's use case sounded a lot like what EKR was describing as his use case for bringing back the new-authz flow. Namely, instead of proactively submitting new-app requests for a bunch of certs, the client would submit new-authz requests for all the names they might want on certs, then submit new-app requests when they're ready to get certs. So basically what you do with LE now, except "new-app" instead of "new-cert". Daniel: That change is in this PR: https://github.com/ietf-wg-acme/acme/pull/165 Does that look like it would address your use case? --Richard > > Regards, > Andrew > > [1] https://www.ietf.org/mail-archive/web/acme/current/msg01160.html > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
