Re: [Acme] Want client-defined callback port

Richard Barnes <> Fri, 17 April 2015 12:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AFFE91B2B87 for <>; Fri, 17 Apr 2015 05:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1ICLmi8nocLK for <>; Fri, 17 Apr 2015 05:08:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D2301B2B85 for <>; Fri, 17 Apr 2015 05:08:57 -0700 (PDT)
Received: by lbbqq2 with SMTP id qq2so81033205lbb.3 for <>; Fri, 17 Apr 2015 05:08:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+J4LFzPzdsxHRQ9STl4wPKusDRYZGl9+QSxtno3FIwg=; b=U8ZvK2XCq43oAjK+h2jdOknGWlrBvXd+SpxpRRjHDaK8c8PZIIA6jRpQh5CvbfnM4c mu9SNl+TMYGFPWz6F3pVKtKX8va1SnnMSlL1C1g/IHTBBRFvbPorrARHS1qnpZBVOwgP YB1fGUPAALu88VVOhpZ7l9DNSmxhT7PI01rKUQ/FwL9u/HSyjcYZfIXfxE57biJSSfRs e2isUiA0S0LFHS7Pq8bGm5wEz2VUAtc46p/QiqxBPfiKd/X80HwZMPtPTnFv/bAx31UE IoBJJtU+9yUjg0cHPMQhaEHExEfckAPXmiBgI99cwFmPzYx/FuMGIaWqAfnHfftgBSNm zJ9Q==
X-Gm-Message-State: ALoCoQlgfrdihhBMAUsY2LygghHtuHrqhtLQIA+KzB2HtSv9uoTiUMwMkvGEKSB1PvXLLUotX5NL
MIME-Version: 1.0
X-Received: by with SMTP id ks9mr2898984lac.49.1429272535892; Fri, 17 Apr 2015 05:08:55 -0700 (PDT)
Received: by with HTTP; Fri, 17 Apr 2015 05:08:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 17 Apr 2015 08:08:55 -0400
Message-ID: <>
From: Richard Barnes <>
To: Bruce Gaya <>
Content-Type: multipart/alternative; boundary=001a1134668aca1e6f0513ea7126
Archived-At: <>
Cc: Nico Williams <>, "" <>
Subject: Re: [Acme] Want client-defined callback port
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, 17 Apr 2015 12:08:59 -0000

On Thu, Apr 16, 2015 at 10:50 PM, Bruce Gaya <> wrote:

> On 16 Apr 2015, at 18:57, Richard Barnes <> wrote:
> Right.  The property that we're trying to authenticate here is that the
> ACME client controls something associated with the hostname.  Ideally, this
> would be the person with write access to the zone file (cf. DNS
> challenges), but to facilitate validation, modern validation accepts
> validation of things like controlling an HTTP or HTTPS server.  It's less
> clear that it would be acceptable to validate that someone can provision a
> service on, say, port 36707.
> That said, the ability to do domain validation without service
> interruption seems like an important requirement.  It seems like the DNS
> challenge listed in the current draft meets that requirement.  We should be
> able to design the simpleHttps challenge so that you just have to to
> provision an extra file on an HTTPS server, not reconfigure it.
> --Richard
> On Thu, Apr 16, 2015 at 8:56 PM, Nico Williams <>
> wrote:
>> You have to be able to prevent unauthorized users from using this
>> alternative callback port to get certs with which to impersonate your
>> service.
> The server (ACME client) computer may be shared between various
> administrators.  It may also have multiple DNS names and host multiple
> services.  If I use ACME to get a certificate for a non-web service, like a
> CalDAV service (default https port = 8443). I do not want to touch or
> reconfigure the web server or (whatever happens to be using port 443) just
> to get a cert for CalDAV.

This argument seems a little confused.  The certificates that CalDAV uses
are not "certs for CalDAV", they're DV certificates just like any others --
if you can get a cert for CalDAV, then you can use it for, say, HTTPS as

>From that perspective, letting the CalDAV admin get a certificate for the
whole domain seems even a little reckless.  Likewise, requiring the CalDAV
admin to coordinate with the HTTPS admin, or someone else in the management
for the domain, doesn't seem unduly burdensome.

Now, if your concern is about CalDAV in particular, and not arbitrary
ports, you could define a validation mechanism that uses CalDAV explicitly,
so that a server could offer to validate that way.  That would address
another major gap in your proposal, namely what interaction should happen
over the client-selected port.


> - Bruce