Hi Richard, Maybe you could elaborate on the bulk-issuance scenarios you have in mind?
Sure! Imagine a provider with a large number of domains wants to perform an initial roll-out by provisioning these domains across a number of certificates. The provider also wants to exercise a finer-grain control over the expiration of these certificates to stagger them across days. With a "on-finalization" based issuance the provider would be free to construct the required applications & complete the challenges for all domains ahead of time as part of one large batch process. The provider can subsequently request certificate issuance on an application-by-application basis across a period of days by completing the finalization. To contrast, with a "go-ahead-and-issue" or proactive issuance model the provider can not authorize all of their domains ahead of time and must complete one application's worth of challenges per day. The provider would be required to split both the authorization and issuance into smaller batches when the intention was to only split the issuance up to control expiry. Does that help clarify? - Daniel/cpu On Thu, Aug 25, 2016 at 2:48 PM, Richard Barnes <r...@ipv.sx> wrote: > Hey Daniel, > > Thanks for doing the research so I didn't have to find those threads :) > > I admit to also being in the "go-ahead-and-issue" camp. To recap, that > would mean: > > 1. Client submits a new application > 2. Server sends back some authorizations > 3. Client fulfills authorizations > 4. Server issues as soon as all required authorizations are fulfilled > > Is there some reason you think a client wouldn't want step (4) to happen? > Maybe you could elaborate on the bulk-issuance scenarios you have in mind? > > --Richard > > > On Thu, Aug 25, 2016 at 1:57 PM, Daniel McCarney < > dmccar...@letsencrypt.org> wrote: > >> Hi folks, >> >> I wanted to revisit a discussion on the server proactively issuing >> certificates. Section 4, "Protocol Overview"[0] currently has a paragraph >> that >> reads: >> >> > Once the validation process is complete and the server is satisfied >> that the >> > client has met its requirements, the server can either proactively >> issue the >> > requested certificate or wait for the client to request that the >> application be >> > “finalized”, at which point the certificate will be issued and provided >> to the >> > client. >> >> There is also an "Open Issue" remark related to proactive issuance in >> Section >> 6.1.3[1]. >> >> I think the specification should decide whether proactive issuance or >> on-finalization issuance should be used instead of allowing both with no >> indication to the client which will happen. >> >> It's the preference of Let's Encrypt that the specification only support >> on-finalization issuance. This is cheaper to implement and seems to be >> the path >> of least surprise. It also seems to better support large volume issuance >> when >> the client may want explicit control over when the certificates for >> multiple >> applications are issued. >> >> 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. >> >> What are the thoughts of other list members? >> >> - Daniel/cpu >> >> [0] https://github.com/ietf-wg-acme/acme/blob/3502ff0bfb6d434b43 >> 26e206ea7cae7b8434ac7d/draft-ietf-acme-acme.md#protocol-overview >> >> [1] https://github.com/ietf-wg-acme/acme/blob/3502ff0bfb6d434b43 >> 26e206ea7cae7b8434ac7d/draft-ietf-acme-acme.md#application-objects >> >> [2] https://www.ietf.org/mail-archive/web/acme/current/msg01160.html >> >> >> _______________________________________________ >> 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
