Re: [Acme] kinds of proof

Paul Hoffman <> Fri, 28 November 2014 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 17A1E1A1B6E for <>; Fri, 28 Nov 2014 13:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ehXjDGB-4LCD for <>; Fri, 28 Nov 2014 13:57:57 -0800 (PST)
Received: from (Hoffman.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D03A1A01EC for <>; Fri, 28 Nov 2014 13:57:57 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id sASLvtmT049364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Fri, 28 Nov 2014 14:57:56 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Fri, 28 Nov 2014 13:57:55 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.1993)
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: Fri, 28 Nov 2014 21:57:59 -0000

On Nov 28, 2014, at 1:37 PM, Viktor Dukhovni <> wrote:
> On Fri, Nov 28, 2014 at 10:37:01AM -0800, Paul Hoffman wrote:
>>> * Does the web server have to be on port 443 with TLS enabled
>>>   (perhaps with a temporary self-signed certificate)?  Or is it
>>>   sufficient to control port 80 or some other port with or without
>>>   TLS?
>>> * If on port 443, is an existing certificate from any of the
>>>   usual public CAs (other than LE) (if also usable as a TLS client
>>>   cert to authenticate to the provisioning system) accepted as
>>>   evidence of authenticity for bootstrapping trust with LE?
>> Why should ability to control port 80 or 443 be a determinant
>> for proving control of "web server" at "domain name"? Not all web
>> service is run on port 80, and not all secure web service is run
>> on port 443. A CA can validate that the requestor can control some
>> HTTP service on some port at the domain name. If a CA has a policy
>> that is more restrictive than that, ACME can trivially support that
>> policy with more error codes.
> Because unfortunately, Web PKI certificates are host-wide, they don't
> specify a port.  Anyone who can run some program on a machine can
> bind to some random port and start a web service.  Possibly port-forwarded
> somewhere else via SSH!
> It is far from clear to me that every "shell" user of a machine
> should be authorized to obtain certificates for the whole machine.

And it is clear to me that they should be, if we want to see more encryption of traffic. I have no problem with some CAs saying "we'll issue you a cert only if you control port X", but I absolutely want that to be a policy of the CA, not of the enrollment protocol.

>>> * If the domain is DNSSEC signed, is it reasonable (I hope)
>>>   to raise the bar, and require proof of DNS control?  Since
>>>   bootstrapping with just web server control and no existing
>>>   credentials is vulnerable to MiTM, and signed domains are
>>>   making an effort to harden against such attacks?
>> I disagree that ACME-the-protocol should raise the bar past what
>> we use for domain verification today. It's fine if a CA who uses
>> ACME does.
> The protocol is just a syntax, and indeed I asking a question about
> appropriate CA policy.  Perhaps some guidance to CAs implementing
> the protocol would not be amiss.

If you want to write such a thing as a separate document whose target audience is CAs, that's grand. It does not belong in the protocol.

--Paul Hoffman