Re: [Acme] kinds of proof

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 29 November 2014 22:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B577C1A01BA for <acme@ietfa.amsl.com>; Sat, 29 Nov 2014 14:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-4IaaFgu31y for <acme@ietfa.amsl.com>; Sat, 29 Nov 2014 14:11:41 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E87A1A016C for <acme@ietf.org>; Sat, 29 Nov 2014 14:11:40 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4D9D6282FD0; Sat, 29 Nov 2014 22:11:39 +0000 (UTC)
Date: Sat, 29 Nov 2014 22:11:39 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: acme@ietf.org
Message-ID: <20141129221139.GL285@mournblade.imrryr.org>
References: <m27fyg4yzg.wl%randy@psg.com> <547754C0.9050306@cs.tcd.ie> <20141127211348.GE25114@mournblade.imrryr.org> <54784C61.2080508@cs.tcd.ie> <20141128170917.GC285@mournblade.imrryr.org> <88B49E1D-1601-4B86-8D93-14CF71501DFC@vpnc.org> <20141128213724.GG285@mournblade.imrryr.org> <7261AA75-5912-4514-A393-94F602C941C2@vpnc.org> <20141129170537.GK285@mournblade.imrryr.org> <046F438F-6230-4A3A-8A5C-708BA91E002B@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <046F438F-6230-4A3A-8A5C-708BA91E002B@vpnc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/1vjC9N6y7ougtKdoFpN7zolZENQ
Subject: Re: [Acme] kinds of proof
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: acme@ietf.org
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Nov 2014 22:11:43 -0000

On Sat, Nov 29, 2014 at 09:22:08AM -0800, Paul Hoffman wrote:

> > Paul, do you have any examples of CAs that accept any port, or are
> > you in part making that up?

Sorry about that, intended to be a harmless off-the-cuff question,
a poor choice of words no doubt.

> When I got a cert for my POP server, what-used-to-be-Verisign
> required the proof of control to be on a port that was not 80.

So they did DV not by email verification, or HTTP, but rather
actually connected to a POP server or similar?

It seems to me that control over something other than ports 25, 80
or 443 is a rather risky choice, and at some point one actually
needs to verify domain control, rather than some arbitrary TCP
endpoint on the host.

> However, "does someone allow it" is completely different than "should this
> new protocol force a business model on all CAs". In the specific case I
> am thinking about, I want a server that will run DNS over TCP to be able
> to get a certificate with ACME. For that, the ability to control port 80
> on the host is completely irrelevant. The same would be true for IMAP and
> POP servers. There are plenty non-web uses of TLS where ACME could be
> useful; hobbling the protocol to be web-only seems premature.

Sure, and the domain owner can field servers on whatever port he/she
wishes after demonstrating control over the domain, which to me
means control over the DNS (be it direct, or indirect via whoever
administers the DNS).

-- 
	Viktor.