Re: [Acme] ACME or EST?

Viktor Dukhovni <> Thu, 27 November 2014 21:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E8F0B1A01FA for <>; Thu, 27 Nov 2014 13:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3dNt4fAdbrOR for <>; Thu, 27 Nov 2014 13:13:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4ADA21A01F2 for <>; Thu, 27 Nov 2014 13:13:50 -0800 (PST)
Received: by (Postfix, from userid 1034) id A63DE28494C; Thu, 27 Nov 2014 21:13:48 +0000 (UTC)
Date: Thu, 27 Nov 2014 21:13:48 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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: Thu, 27 Nov 2014 21:13:53 -0000

> Not much tbh, far less than getting something that can be
> turned on by default. And ISTM that any of the reaosnable
> choices, about which we sometimes endlessly debate, all
> work.

I agree that the wire format (syntax) is less important than the
feature set (semantics).  In particular, there I'd like to see some
discussion of what kind of "proofs of control" should be acceptable
with a lights-out DV certification authority.

A certification authority that issues a cert to anybody who asks
without any evidence of domain control may employ the most cool
message syntax and still be a bad idea.

A certification authority that makes it too difficult for most
domains to prove the legitimacy of the request would be pointless.

A certification authority that always accepts the weakest form of
evidence even for domains that should be able to present stronger
evidence would be unfortunate by bringing everyone's security down
to the lowest common denominator.

In terms of protocol standards, sure, encodings need to be discussed
and message structures agreed, ...  However, at the end of the day,
the trade-offs that LE will make between security and usability
are what really counts.