Re: [Acme] Issuing certificates based on Simple HTTP challenges

Michael Wyraz <michael@wyraz.de> Wed, 16 December 2015 19:30 UTC

Return-Path: <michael@wyraz.de>
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 69F2D1A88D6 for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 11:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 HOMBgPSCpauG for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 11:29:59 -0800 (PST)
Received: from mail.wyraz.de (web.wyraz.de [37.120.164.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C39F1A88C3 for <acme@ietf.org>; Wed, 16 Dec 2015 11:29:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.wyraz.de (Postfix) with ESMTP id 3D87AA36B1 for <acme@ietf.org>; Wed, 16 Dec 2015 20:29:57 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at web.wyraz.de
Received: from mail.wyraz.de ([127.0.0.1]) by localhost (web.wyraz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p3JsEk-oKgH for <acme@ietf.org>; Wed, 16 Dec 2015 20:29:56 +0100 (CET)
Received: from [192.168.1.200] (p57857E5C.dip0.t-ipconnect.de [87.133.126.92]) (Authenticated sender: michael@wyraz.de) by mail.wyraz.de (Postfix) with ESMTPSA id A7A35A36B0 for <acme@ietf.org>; Wed, 16 Dec 2015 20:29:56 +0100 (CET)
To: acme@ietf.org
References: <CAF+SmEpOLoaREymVhi=qOUg2opz1vKzzNp6tGrDTZAjYSKFDkg@mail.gmail.com> <566F15DC.7090607@wyraz.de> <6B677A87-C6A0-485E-80DF-24960D585F46@coderanger.net> <566F2CB5.90402@wyraz.de> <89774336-0BA6-48FC-821D-1E8F3ED9AC14@coderanger.net> <566F4701.7050308@wyraz.de> <F3DA31B1-B27C-4C63-8ED4-6D27D46FF282@coderanger.net> <C2C239F2-E8A7-499B-BE52-3A48EA92B86D@dropmann.org> <BF7F8411-3E83-4A1F-B3A1-4C37DC8B4618@coderanger.net> <3CDE1749-3143-49EE-BD66-0AE4A8CC4175@dropmann.org> <566FDAB7.2030403@cs.tcd.ie> <56700F68.3040103@wyraz.de> <56701904.2070009@cs.tcd.ie> <56702EFA.1050008@wyraz.de> <13B5E9A8-E9CE-4018-8A9D-7856CBF06B4F@coderanger.net> <CAMm+Lwhvf+nRVV38q1U1DKm1WStV1UJv4+EJ_zvq0G_Tb25S9w@mail.gmail.com> <2761E0B2-8DCC-4150-813F-8CAB756C0392@coderanger.net> <174B082E-2721-41AE-992D-2937DCCB74CB@dropmann.org> <894b0ad1f1c34184bbbc9133702ed474@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Michael Wyraz <michael@wyraz.de>
Message-ID: <5671BBB5.4050308@wyraz.de>
Date: Wed, 16 Dec 2015 20:29:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <894b0ad1f1c34184bbbc9133702ed474@usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="lTSPfDRRFVQPJpfCqA9ONN6SqTPn16cAn"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/xceu8kEBKABIzX0GCweGwM6DJJo>
Subject: Re: [Acme] Issuing certificates based on Simple HTTP challenges
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 16 Dec 2015 19:30:00 -0000

This discussion is more and more about the question if ACME should use a
SRV record instead of a A record (as a replacement).

Personally I think that using an optional SRV record for ACME with
fallback to A record would be the best solution for all use cases. Those
who can not or don't want to setup a SRV record for ACME can use http-01
as it is. Those who sets SRV for ACME can exactly specify which host is
allowed to to ACME http-01.

An optional ACME SRV record in the spec would make all happy: Those who
only have A-record. Those who want to create certs for devices that
cannot answer to the challenge (e.g. switches). Those who have geo-based
dns (while A-record is geo-dependent, ACME SRV would point to one single
location). Those with multiple load-balances backends. And even those
who simply don't want anyone to create certs who has an A-record
delegated to (like Julian, he can simply create such a record and point
it to NIL).

Oh and of course the programmers of the acme client (no change needed
for most-common use case) and server (just a few more lines of
dns-lookup-code to determine the host to which they need to talk for
challenge).

I can't see any drawbacks this change would bring to ACME, LE or it's users.

Kind regards,
Michael.