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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 16 December 2015 14:39 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 DA0C31A88AC for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 06:39:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 CTp724gkNmPB for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 06:39:39 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 A57201B2DE0 for <acme@ietf.org>; Wed, 16 Dec 2015 06:39:38 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id y184so30595600lfc.1 for <acme@ietf.org>; Wed, 16 Dec 2015 06:39:38 -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=80Evm5SuUdgi1ytojJe9jGOHoHiwRY5mlcZIoFQ943g=; b=serioHNvKuS9P0eeFVbBZiqYmgoCrbQVvST9Q25kAAM/hD0pwsZ1/n35OkVGrbwzcv HUN5ZYXmImq0YmoNWq7WEbXR0H9sndEki5TGxFW/KyFcKra/oRnEEP708OSUgE5LX3uz CeKrEEfZT6/kKUEq/ACxGzpFL/5OIaDXhRkJBKCLrqqzSOx5MzBqvn/VexzjkhNQ1DdT aQSr+wNZglv/eXAluJ+GhvmctmCBRTGSLpWAIAii8MjHL/CRTk/qQkFtCeF53R9gfFkZ nRZ1q1l3X1el+og183c1IgXsq1AdfyinDhIMY+b43RwtZyz6Z+j/s9kDY0tdz9HoC4m7 O/Ow==
MIME-Version: 1.0
X-Received: by 10.25.84.76 with SMTP id i73mr2988790lfb.43.1450276776804; Wed, 16 Dec 2015 06:39:36 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.1.227 with HTTP; Wed, 16 Dec 2015 06:39:36 -0800 (PST)
In-Reply-To: <56716964.7070001@cs.tcd.ie>
References: <CAF+SmEpOLoaREymVhi=qOUg2opz1vKzzNp6tGrDTZAjYSKFDkg@mail.gmail.com> <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> <5670CBD6.5080000@cs.tcd.ie> <CAF+SmEp494K9pQqWNAeH1iS+dsmLSMJnuMpAvjGm0dku3ukEfQ@mail.gmail.com> <56715280.2070600@cs.tcd.ie> <CAF+SmEqND_9bxroNkr72woY9UBjP3BaUS1FbQa44jzfRWR1v+g@mail.gmail.com> <56716964.7070001@cs.tcd.ie>
Date: Wed, 16 Dec 2015 09:39:36 -0500
X-Google-Sender-Auth: QAUcSuUZ9QLBLQKIJkScdRtdT5A
Message-ID: <CAMm+Lwhk3ruSHSepCZmB1Z5b3k3vSsy5ZQJx03wNUYCnPFZwDA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="001a114069da1b8543052704e00c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/FtVpIR4UksYS3efWpuMkjWADauk>
Cc: "acme@ietf.org" <acme@ietf.org>, Noah Kantrowitz <noah@coderanger.net>, Julian Dropmann <julian@dropmann.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 14:39:41 -0000

On Wed, Dec 16, 2015 at 8:38 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
>
> On 16/12/15 12:20, Julian Dropmann wrote:
> > If they trust you with that, they could just add an ACRE specific SRV
>
> (ACRE? You mean acme I guess.)
>
> > record, and thereby delegate that privilege to create certs to you and
> > everything would be fine.
>
> Yes. They could. But they won't;-)
>
> And as it happens in my own specific case I don't want the ability
> to get a cert for any name in the relevant zone, I only want to be
> able to get and renew certs for the names of my web servers. So the
> semantics of the thing you'd put in DNS (or the thing to which it'd
> point) would likely end up quite complex. It'd end up much like an
> RA is my guess, and I really don't think we want to go there yet
> with acme.


If the requirement is for an RA, you are not going to end up with a simpler
protocol if you insist on giving people umbrellas instead.

The reason the introduction of an RA simplifies the protocol is precisely
because it removes the need to validate the RA for each cert issue. The
RA validates once (a year), is issued a PKI credential and then uses that
to authenticate each request.


Stephen's situation is not typical of Enterprise but it is very typical of
academic
and SOHO environments.

> They were able to do this with the A record too.
> >
> > I just do not find it intuitive in general that by defining any record
> you
> > do this implicitly as a domain owner.
> > At least I personally was not expecting this, but maybe its just me that
> is
> > so stupid.
> >
> > And the question was not about whether you personally are legitimated to
> > create certs for your university, but whether this should be the case for
> > any host of every single zone.
>
> Not "any host" but any host that runs a web server and where the
> entity requesting the cert demonstrates control over that web server.
> I think that is fine in general myself.


It all depends on what your requirements are.

My immediate requirement is to make the certificate warnings 'go away' on
my internal server boxen without me spending money. They are behind a NAT
and there is no way to change that.

The NAS boxes are running a version of Linux but the whole point of getting
a package deal was to avoid maintenance issues. A proposal that requires me
to write a half dozen scripts is not going to be any easier for me to
manage than my current solution of a local CA whose root I install on every
machine when I accept it into the network.