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 <[email protected]> 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/ > 3502ff0bfb6d434b4326e206ea7cae7b8434ac7d/draft-ietf-acme- > acme.md#protocol-overview > > [1] https://github.com/ietf-wg-acme/acme/blob/ > 3502ff0bfb6d434b4326e206ea7cae7b8434ac7d/draft-ietf-acme- > acme.md#application-objects > > [2] 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
