On Fri, May 06, 2016 at 03:19:56PM -0400, Richard Barnes wrote: > Hey all, > > Just posted a PR with a sketch of the "precondition" idea that we discussed > at the F2F in Buenos Aires:
I like the idea of having more structured 'error' reporting for things like this. > 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 How is this different to requesting authz for *.example.com and having it tell you what you need to do in response to that? > * 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. Related to this, I wonder if we also need a method for the client to be able to tell the CA "You should only accept/offer authz performed with [array of methods]". I see (at least) two reasons this might be desirable. In practice, we're seeing that for many users only a subset of the possible methods are actually practical for them to deploy (and provisioning challenges that that the client knows it will never legitimately try to perform seems less than optimal). And in some cases it might be desirable to limit the privilege required to complete a challenge. ie. the owner of an identifier might want to declare that only the DNS admin should be allowed to prove authz, but they may allow people with lesser privilege to update content in their web space (without wanting to give those people the ability to obtain authz for issuing certificates). That has some of the same problems that CAA does, but it still seems better for the client to be able to say "I only want authz with these methods" up front than to have the server say "any of these things _we picked_ can now be used, by anyone who can do them, to obtain authz for your requested identifier". > 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. I'd like to see a bit more justification for adding that extra complexity. Having a situation where an identifier is or isn't authorised only under some complex rules that only sending a CSR can resolve seems like something we should be able to solve in some simpler and more straightforward way. > But I thought I'd go ahead and send this first pass out for feedback. > > What do people think? > +Sometimes a client might make a request of an ACME-enabled CA without having > +performed some actions that the CA requires before processing the request. I'd like to see us precisely define which requests can invoke this mechanism, especially if one of its side effects might be things like pre-provisioning authz. > + "type": "registration", > + "required": ["contact", "terms"] Did you mean ["contact", "agreement"] here? (though it might be nice for both that and "terms-of-service" to actually be the same field name consistently everywhere). > + "type": "authorization", > + "url": "https://example.com/acme/authz/asdf1"; If we are going to do this, I'd like to see it also include the "identifier" object (as would have been submitted with new-authz) so that the client can know what retrieving that URL should return (especially if there may be more than one of them for a single request). But I wonder what the pre-provisioning here gains us (except yet another path to perform the same task)? Wouldn't it be better to just report that you need authz for one or more identifiers and let that be done in the normal way? The more ways we have to do the same thing, the more likely it is that someone will eventually find unintended consequences they can have fun boring holes through ... Cheers, Ron _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
