Based on the discussion on this thread it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations.
I opened a PR [0] that changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. I think this should wrap up the discussion in a way that is satisfying for everyone that has voiced an opinion so far. Thanks! [0]: https://github.com/ietf-wg-acme/acme/pull/191 On Fri, Aug 26, 2016 at 2:46 PM, Roland Bracewell Shoemaker < rol...@letsencrypt.org> wrote: > On 08/25/2016 03:15 PM, Richard Barnes wrote: > > > > > > On Thu, Aug 25, 2016 at 5:41 PM, Andrew Ayer <a...@andrewayer.name > > <mailto:a...@andrewayer.name>> wrote: > > > > On Thu, 25 Aug 2016 13:57:25 -0400 > > Daniel McCarney <dmccar...@letsencrypt.org > > <mailto:dmccar...@letsencrypt.org>> 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 > > Acme@ietf.org <mailto:Acme@ietf.org> > > https://www.ietf.org/mailman/listinfo/acme > > <https://www.ietf.org/mailman/listinfo/acme> > > > > > > > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
