Re: [Acme] ACME or EST?

[Nico Williams <[e-mail]>]

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.

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?

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?

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.

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

"
   It is assumed that clients are configured with this URI out of band.
"

Clients could learn it via RFC5988 link relations, no?

"
   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), ...?

Nico
--