Hi Andrew, Thanks for the follow-up.
> 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]. Ahhh! Yes, this sounds like a sensible reason to prefer proactive issuance. I will review your previous email with details and will reevaluate my position. > 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? Yes - this might be a good compromise. I'll try and take some time to compare this versus the EKR PR[0] for the new-authz flow that Richard linked to in his other reply to this thread to see if one is a better fit than the other. My primary motivation for this thread is to decide on *one* method: proactive or on-finalization. If the proactive approach can support the bulk issuance case then I could be persuaded to support it as the One True Issuance Method :-) - Daniel (P.s. my timing here wasn't ideal and I leave for vacation today. I will have to pick this thread up in a weeks time, apologies!) [0] https://github.com/ietf-wg-acme/acme/pull/165 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]. > > 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. > > 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
