Re: [Acme] kinds of proof

Trevor Freeman <> Tue, 02 December 2014 19:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AD4A71A1EF7 for <>; Tue, 2 Dec 2014 11:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dq_zPcOFhY4v for <>; Tue, 2 Dec 2014 11:36:26 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 592651A6FE2 for <>; Tue, 2 Dec 2014 11:36:26 -0800 (PST)
Received: from Den ( []) by (Oracle Communications Messaging Server 64bit (built Aug 27 2014)) with ESMTPSA id <> for; Tue, 02 Dec 2014 19:36:25 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-02_08:2014-12-02,2014-12-02,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412020167
From: Trevor Freeman <>
To: 'Paul Hoffman' <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-reply-to: <>
Date: Tue, 02 Dec 2014 11:36:18 -0800
Message-id: <007501d00e67$3f0b2620$bd217260$>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0076_01D00E24.30EE00A0"
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQGSAWoMOWbPM63Lg/bucBKRIHyRQwI/XhhvAhyJYcsBIF/JYQKjNS8FAafZ1toB1+EZBQGt8DVOAc9pp/8CXEbkjQJll7srAw5ul9gBnkNCnJw0bKgg
Content-language: en-us
Subject: Re: [Acme] kinds of proof
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, 02 Dec 2014 19:36:29 -0000



-----Original Message-----
From: Acme [] On Behalf Of Paul Hoffman
Sent: Tuesday, December 02, 2014 9:30 AM
Subject: Re: [Acme] kinds of proof


Greetings. It seems that some people want ACME to force a higher level of
assurance on the protocol than those of us who are trying to get more
authenticated encryption everywhere would want. Given that we still don't
have a published Internet Draft (ahem), it would be good to come to
agreement early on what is going to be required.


A specific use case that is important to me is someone running a web server
on a commercial hoster should be able to get a TLS cert using ACME even if
the hoster does not have its own ACME support. The site admin in that case
should be able to run an ACME client on their laptop and be able to go
through the ACME steps needed to get a cert that they can load into their
web site, then tell the hoster to turn on port 443.


If the hoster supports the ACME steps itself, the web admin might not even
need to do anything: the hoster can run ACME for them to get the cert. Given
that hosters are always trying to cut customer service costs, ACME should
allow hosters to automate the cert process to the point where no human
interaction is needed after the hoster decides "this site will now use




- ACME clients and servers can be run without human interaction during the
ACME exchange itself. All configuration can be done before the ACME client
initiates the session, as long as the system running the ACME client has
control over the service for which the certificate is being issued. A human
may need to make manual changes if their system does not have an ACME setup,
but the ACME protocol supports full automation as well.

[TF] Totally agree with the sentiment. However each ACME client will need
some minimal configuration and I stress minimal. I would submit it should be
possible to use:

1.       The URL of the ACME server

2.       An authenticator to prove this request belongs to a DV RA

That is all we need. The ACME client should be able to use this data to
learn when type of request(s) to build, what parameters to use, then summit
the request with a high confidence it will success because it used the
information from the ACME server to build the request, and install the
certified once issued. The small the bootstrap data set, the less scope for
misstates when repeating across multiple ACME clients. 


- A CA must verify that the system on which the ACME client is running can
control the service for which the certificate is being issued.

[TF] The ACME server would have previously verified the DV RA. The biding
between the RA and the individual request is a form of delegations i.e. this
request belongs to the DV RA. 


- The system running the ACME client does not have to have control over the
DNS service that controls the domain name being used in the requested
certificate; however, particular DNS control can be required by policy by an
ACME server.

[TF] This relates to the type of proof and scope the DV RA used. If the DV
RA used a DNS based POC then the CA can issue names in any subdomain i.e. if
you validated then you can issue * If the POC was to a
specific URL, then the ACME server can only issue to that same domain name. 


- The ACME protocol has to have expressive enough semantics so that an ACME
server can tell an ACME client in detail what policy is causing the ACME
server to reject a particular certificate request.

[TF] an ACME server can tell an ACME client in detail what is causing the
ACME server to reject a particular certificate request.  Let's not assume
the only failures are policy.




Acme mailing list