On Wed, Jul 6, 2016 at 12:52 PM, Eric Rescorla <[email protected]> wrote:
> > > On Wed, Jul 6, 2016 at 8:01 AM, Richard Barnes <[email protected]> wrote: > >> In preparation for the impending draft deadline, I'm trying to finalize >> close this out. It seems like there's some positive reaction to the >> "revise the flow" idea, so I wanted to make a concrete proposal: >> >> 1. Add a section specifying the order of operations for the client: >> - Register if you haven't done so before >> - Send a new-cert request >> - Get back preconditions; satisfy them >> - Retry the new-cert request >> > > I have the same concerns about this that I had in B-A. This seems to put > the client in a position of having to continuously fulfill new requirements > without any guarantee that it will ever lead to success. That seems bad. > It's not like the client was guaranteed of success in the original model, except under simplistic assumptions about the CA's policies. And it's not like it's really in the interest of either party to end up in this situation. We already have examples of CAs that won't specify their requirements for validation until you've sent a CSR (see the SSLMate API as a proxy for a few of them). I'm not sure how to accommodate that without ending up in the situation you're concerned about. I suppose you could require that the server specify all of its preconditions in the first response, but it's hard to see how to make that stick. Maybe the best compromise here is to provide guidance: (1) when a server issues preconditions, it should specify everything that's required, rather than specifying them iteratively, and (2) clients should track how many times they've gotten preconditions for the same request and abandon the request if the server is being unreasonable. --Richard > > -Ekr > > >> 2. Remove the new-authz URL >> >> Obviously (1) could make for some slightly complicated state management >> on the CA side in some cases, if the CA needs to carry any state between >> the first new-cert request and the second. But it seems like this can be >> managed, e.g., by carrying state in the authz URLs or the authorizations >> themselves. And it is technically possible to do it entirely statelessly. >> >> Removing the new-authz URL isn't strictly necessary. You could leave it >> there as an optional service ("if new-cert in directory {...}"), but >> removing it seems more in the spirit of Langley's "have one joint and keep >> it well oiled" principle. And while it's a hard breaking change, CAs can >> migrate gradually by leaving it on for a while. >> >> Obviously, the deadline is coming up quickly, so it would be great to get >> feedback today-ish. It's not critical that we get all the comments now; we >> can discuss between now and the meeting. This is just a non-trivial bit of >> work, so I wanted to sanity check before I embarked on it. >> >> Thanks, >> --Richard >> >> >> >> On Fri, May 6, 2016 at 3:19 PM, 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? >>> >>> Thanks, >>> --Richard >>> >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
