Subject: [Acme] Preconditions

From: Richard Barnes <[email-masked]>
Date: Fri, 6 May 2016 15:19:56 -0400

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

---

From: Andrew Ayer <[email-masked]>
Date: Fri, 6 May 2016 13:52:29 -0700

On Fri, 6 May 2016 15:19:56 -0400
Richard Barnes <[email-masked]> wrote:

> Hey all,
> 
> Just posted a PR with a sketch of the "precondition" idea that we
> discussed at the F2F in Buenos Aires:
> 
> * 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
> 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.
> 

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

---

From: Ron <[email-masked]>
Date: Sat, 7 May 2016 16:45:04 +0930

> at the F2F in Buenos Aires:

I like the idea of having more structured 'error' reporting for things
like this.

> * 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?

> 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".

> 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.

> +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