On 08/25/2016 03:15 PM, Richard Barnes wrote: > > > On Thu, Aug 25, 2016 at 5:41 PM, Andrew Ayer <[email protected] > <mailto:[email protected]>> wrote: > > On Thu, 25 Aug 2016 13:57:25 -0400 > Daniel McCarney <[email protected] > <mailto:[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. >
In the current model would the idea be you could 'finalize' an application multiple times and the 'certificates' field would include the array of certificates created from that application in some defined order? This would be a very nice thing to have from the server side. > 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". > I think this adds unneeded complexity and only makes sense if we decide to make proactive issuance a 'MUST' and still need a way for people to create applications with new authorizations without immediately creating the certificate. Thinking about it more I do kind of like the idea Andrew brought up, or really a mutation of it, where the application has a field that lets the client define if they want the application to complete itself if possible. > 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 > <https://www.ietf.org/mail-archive/web/acme/current/msg01160.html> > > _______________________________________________ > Acme mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
