Re: [Acme] ACME or EST?

Nico Williams <> Tue, 25 November 2014 22:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 83E101A7003 for <>; Tue, 25 Nov 2014 14:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4WqEPtE6ZQ3Y for <>; Tue, 25 Nov 2014 14:37:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7A06D1A1A64 for <>; Tue, 25 Nov 2014 14:37:18 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 393C426C063; Tue, 25 Nov 2014 14:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=cXNFqJI9M4iXpU jEW7JrM7mnHKQ=; b=GB+4YGcC6DAO8o7w80bZ/Qj/IdJWzWMfJPcIQ/Bj+ajx36 67gxXQhEym5wINwdSypPbYGk6pJ0xtb1S5t3pGoVSpc5hdrUZtE08SuZNyg535pw 2mCCptNx0Kqk+BgkFLqfhLRJ+I9fCHCVab6mdqDu0canxSbWZ/jJ9gzMiNo3s=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id D7B5726C05E; Tue, 25 Nov 2014 14:37:17 -0800 (PST)
Date: Tue, 25 Nov 2014 16:37:17 -0600
From: Nico Williams <>
To: Richard Barnes <>
Message-ID: <20141125223715.GV3200@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc:, Paul Hoffman <>
Subject: Re: [Acme] ACME or EST?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Nov 2014 22:37:19 -0000

On Tue, Nov 25, 2014 at 04:55:51PM -0500, Richard Barnes wrote:
> On Tue, Nov 25, 2014 at 4:41 PM, Paul Hoffman <> wrote:
> > This overlaps a lot with "Enrollment over Secure Transport" (EST), <
> >>gt;.
> >
> > 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

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