[Acme] Usage of HTTP Re: ACME or EST?

[Richard Barnes <[e-mail]>]

(new subject, since we're diverging from EST)

On Tue, Nov 25, 2014 at 5:37 PM, Nico Williams <[e-mail]>
wrote:

> On Tue, Nov 25, 2014 at 04:55:51PM -0500, Richard Barnes wrote:
> > On Tue, Nov 25, 2014 at 4:41 PM, Paul Hoffman <[e-mail]>
> wrote:
> > > This overlaps a lot with "Enrollment over Secure Transport" (EST), <
> > > https://tools.ietf.org/html/rfc7030>.
> > >
> > > For many people who saw last week's announcement, the main use case of
> > > ACME is "make it easy to create a client that can create a key, get it
> > > enrolled with a server, get the new certificate back, and install that
> > > certificate in a web server". What does/will ACME offer that EST does
> not
> > > already?
> >
> > A few things off the top of my head:
> >
> > * If nothing else, much less ASN.1.  (Cf. JOSE vs. CMS)
>
> RFC7030 defines very few new ASN.1 types... oh.  It uses the ASN.1 IOS.
> Eww.  Yeah, OK, I see your point.
>

It's not just the new ASN.1, it's the re-use of CMC structures as well.



> That ugly ASN.1 in RFC7030 is for the response to a "request
> required/desired attributes" request.  Your I-D doesn't have this
> feature, presumably because there's no real need for it.  Can you
> confirm?
>

Right now, there's nothing similar.  It will probably ultimately be useful
to have some sort of description of what CSRs will be acceptable, but it
seems like you could do that in JSON.



> A request for supported attributes might be useful, but probably only
> for purposes _other_ than HTTPS servers.
>
> (If there were a need for such a thing then defining ASN.1 types that
> don't use the IOS would be trivial.  Using JSON would be fine too, and
> since that's what you prefer, go for it.)
>
> > * Support for other certificate management functions, e.g., revocation
>
> And rollover?  And re-certification?
>

Rollover, yes.  When re-validation of possession of the identifier isn't
needed, there's a renewal URI.

Re-certification, yes.  Just re-do the identifier validation, possibly
using the "proof of possession of previous key" to ensure continuity (or
just observing that the same key pair is used).


I mean, one of the most useful features would be to have fresh and/or
> short-lived cert management to avoid revocation: re-certify the
> EE's cert frequently, even when there is no key rollover.
>
> Among other things it'd make OCSP stapling less necessary.
>

Right.  That's the idea of the renewal URI in the certificate message -- so
that you can get new certs with the same content as long as the
authorization for the identifiers in the cert is valid.



> > * Validation of possession of identifiers
> > * Cleaner use of HTTP
>
> "
>    All requests for a given ACME server are sent to the same HTTPS URI.
> "
>
> I'd expect different kinds of requests to use differen URIs (that seems
> to be best practice, but then again, you're not claiming that ACME is
> RESTful, so hey).
>

The guidance I've gotten from the HTTP community is: "DO NOT place
constraints on the format of URIs, except for within .well-known"

The two ways to comply with that are (1) to use the same URI for
everything, or (2) to start from a single URI and discover other URIs
through the protocol.  Option (1) seemed simpler for this protocol.



> "
>    It is assumed that clients are configured with this URI out of band.
> "
>
> Clients could learn it via RFC5988 link relations, no?
>

Sure.  That would still be out-of-band w.r.t. ACME.



> "
>    ACME requests MUST use the POST method, and since they carry JSON
>    ...
> "
>
> Er, are there no requests for information?  E.g., OCSP Responses,
> acceptable attributes (for CSRs), ...?
>

There are, but I had considered them outside of ACME.  For example, for
cert renewal, you just do a GET to a URL provided by the server.

--Richard



>
> Nico
> --
>