On Fri, 6 May 2016 15:19:56 -0400 Richard Barnes <[email protected]> wrote:
> Hey all, > > Just posted a PR with a sketch of the "precondition" idea that we > discussed at the F2F in Buenos Aires: > > https://github.com/ietf-wg-acme/acme/pull/124 > > This change seems pretty simple, and I think it lets us hit a few pain > points: > > * Wildcards: Just send the CSR in and let the CA tell you what to > validate > > * Payment: Specify an "out-of-band" precondition > > * CA issuance flows: If the CA won't tell you how to authorize until > you send in a CSR, this now lets the ACME server lead the client to do > authorization after the new-cert request comes in. > > We may need a little more machinery here, e.g., to be able to have the > new-authz endpoint say "that's not going to work directly, just > request the cert". We may even want to just revise the flow, so that > instead of reg-authz-cert, the default order is reg-cert-authz-cert. > > But I thought I'd go ahead and send this first pass out for feedback. > > What do people think? Hi Richard, I like it! I think it would make ACME work well with CAs where authorizations are tied to a particular CSR. I also like the idea of changing the default flow to reg-cert-authz-cert. Even when authorizations aren't tied to CSRs, I think it would simplify the client, particularly when reissuing a many-SAN certificate with an additional SAN. Instead of having to check every existing authorization to see if the client needs to create a fresh authorization for an identifier, the server could just tell the client using preconditions. Regards, Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
