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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 16 December 2015 19:54 UTC

Return-Path: <hallam@gmail.com>
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 469EB1A8792 for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 11:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 3Jdtt6lT5htK for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 11:54:01 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CBD1A88DF for <acme@ietf.org>; Wed, 16 Dec 2015 11:54:01 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id p203so37577541lfa.0 for <acme@ietf.org>; Wed, 16 Dec 2015 11:54:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gBzC1Pz7hTKZQFD8+Y+zhsmgMNfJ0UT1svhlr/ilk4k=; b=owzmqpzpQqr5glH4mRIkorGfc9zLFLoflV7f4rsf+OPCYBN79zlvO4XYuPeSazaBbQ L03zjeB7wB9QPLeD7oZ4bs0VoJwI13FUlJsODGzIZWlYxqAc5pqzeIYLaa5ZjRJHDuwI BBy31TgEr7/61K950afYaycIC2jHDERMuvjlOKX4apZcsVakjc01hjuQUpDWTNMYDYeN e/fuTXEKAKT9QDSj6aPGMFpCYKQTt554Ycg+UoEALZtu0pJLMqOjT3jjk5ig+43E9Qia +OltmZxWy5kiXNsSs32TjISlSGEJOuQBjATg0Wb+rhdP8cevvLESxGNTBDRiQLVNIM25 Rh6w==
MIME-Version: 1.0
X-Received: by 10.25.206.203 with SMTP id e194mr15761382lfg.166.1450295639647; Wed, 16 Dec 2015 11:53:59 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.1.227 with HTTP; Wed, 16 Dec 2015 11:53:59 -0800 (PST)
In-Reply-To: <5671BBB5.4050308@wyraz.de>
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> <5671BBB5.4050308@wyraz.de>
Date: Wed, 16 Dec 2015 14:53:59 -0500
X-Google-Sender-Auth: sEIJeY6QHsw2cdm4q_yEUxetEVs
Message-ID: <CAMm+LwjGcvnfxnpswFRcTuCHydc=xVbgGa7UYmZS0sskTsdXpA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Michael Wyraz <michael@wyraz.de>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/wRBaHPRP1yJo3RuF_nT1p08am0E>
Cc: "acme@ietf.org" <acme@ietf.org>
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:54:05 -0000

On Wed, Dec 16, 2015 at 2:29 PM, Michael Wyraz <michael@wyraz.de> wrote:
> 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.

Just a point of clarification. This would be an SRV record for the
ACME *Challenge response validation protocol*. That is a quite
different matter from having an SRV record for the ACME protocol.

The difference is that the two go in completely opposite directions
and identify parties acting in precisely the opposite roles.

So I suggest using _acme-validate._tcp and _acme-issue._tcp for the
SRV prefixes.


This would certainly allow some cleanup of the client implementations.
I might set up a daemon to run once a day that has a list of all the
certificates that particular host needs to run. It then fires off a
cert request for anything that is nearing expiry and then listens for
a challenge on whatever port the challenge is going to arrive.

In a NAT environment, I would create a separate external domain name
and SRV record for each host and give each one a different port
number. These would then fan out to the corresponding cert maintenance
daemon at the NAT.

The alternative to using SRV would be to do 'something' with CAA. But
I think that is best reserved for putting an RA key there.