On 08/25/2016 02:41 PM, Andrew Ayer 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]. >
This is a very interesting idea that is worth considering but perhaps as an extension to the ACME specification rather than an initial part of it? A move to this style of issuance would require major architectural changes to all existing server and client implementations, something I'm unsure there is much enthusiasm for at this point. > 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. > You refer to enabling/disabling an authorization but it seems like you mean the application? If that is the case this seems to be essentially the same as having two step issuance except it is possible to default to 'issue instantly'. I'm not entirely convinced this wouldn't work but I am much happier increasing complexity on the side of the client than the server which this would do the opposite of. > 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
