Re: [Acme] Why "HTTP verification"

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 02 December 2014 21:53 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 5CA751A6FB6 for <acme@ietfa.amsl.com>; Tue, 2 Dec 2014 13:53:52 -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 cySc9Z7eEODp for <acme@ietfa.amsl.com>; Tue, 2 Dec 2014 13:53:51 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F7B1A6F40 for <acme@ietf.org>; Tue, 2 Dec 2014 13:53:50 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id l4so10989744lbv.39 for <acme@ietf.org>; Tue, 02 Dec 2014 13:53:49 -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=b9CNTHM4fRymfoUB1ghtbO6D1u75ydFP2oysXdDcIzg=; b=aQYLYF2BDjncGG9/XvUi6QSM2XBWc8uE7NZ4vHbKMmKCYH1aIQIMJcKkack1q+MBYG fKGV8pmbAfKIErxXdwfADJ5rhV3i/N5zSZK1VRCvYDOyRXQAPwAc68TK/wjW1tugvpnD 3VldlScLi8huyzZf0O65s/Gyw+FC60EMQYbHFiKx3AQEduWUdOZme4Bpqy7UztyEK6yb ilj7oWGc1s3IapwBuCfBVJbC2Qe7GetNKU8xW1Iw8HH48SCGL6XiudAABjyROLs2NpvT /4pB5GRQitHTAh9NVS+WRW1n6abKTMYnQy+Ll1kb851GDcdXPZ+BD5K+xR5QOpBCwOs6 AVnA==
MIME-Version: 1.0
X-Received: by 10.152.116.79 with SMTP id ju15mr1318251lab.84.1417557229233; Tue, 02 Dec 2014 13:53:49 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.19.42 with HTTP; Tue, 2 Dec 2014 13:53:49 -0800 (PST)
In-Reply-To: <CAK6vND9GcnQ1UbrLd6osj4vQ-GDr5Gwwh-Cx97nSHw-z3i5Vkw@mail.gmail.com>
References: <B80ACB30-1A35-440E-B250-AB8C80D1FAF1@vpnc.org> <CAK6vND-001PK0gP_3Txoge2hvYiKPuA+trd9zj7PzaooOOMH3A@mail.gmail.com> <20141202194441.GA285@mournblade.imrryr.org> <CAK6vND9GcnQ1UbrLd6osj4vQ-GDr5Gwwh-Cx97nSHw-z3i5Vkw@mail.gmail.com>
Date: Tue, 02 Dec 2014 16:53:49 -0500
X-Google-Sender-Auth: v0gkImTnAWysdxxzgHV_dE7z3C0
Message-ID: <CAMm+LwjumV1AGpWEA0Cj2wJh0LFoVM18fhvjWQv+ZoNTL36b-g@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Peter Bowen <pzbowen@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/kcJ_V5m-vHvxHiMPzZZsYPWdEk0
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Why "HTTP verification"
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: <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: Tue, 02 Dec 2014 21:53:52 -0000

On Tue, Dec 2, 2014 at 4:41 PM, Peter Bowen <pzbowen@gmail.com> wrote:
> On Tue, Dec 2, 2014 at 11:44 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> On Tue, Dec 02, 2014 at 11:15:40AM -0800, Peter Bowen wrote:
>>
>>> The primary case where I see a problem is when the site already has a
>>> trusted certificate and wants to use ACME to get a new certificate.
>>> They are unlikely to want to replace their working certificate with a
>>> self-signed certificate.  So the proof would need to happen at the
>>> HTTP layer, not the TLS layer.
>>
>> They can request a certificate for the same private key.  The
>> "self-signed" thing so not precise.  The real requirement would be
>> *some* certificate with the same key, not necessarily self-signed.
>> So issued by another CA should be fine.
>
> I would hope that many sites would have a policy of rotating their
> private key, as a reasonable number of clients still use the same key
> for identification and key exchange.  I'm not sure what the protocol
> should look like for proving possession of the old and new keys at the
> same time, but it would be good to support this case.

Absolutely!

Rotating the private key is one of the biggest potential wins here.
There are good reasons for not rotating keys on Key Signing Certs in
certain situations but the only reason it doesn't get done on end
entity certs is the problematic management protocols.

Automating the issue means we can drop the cert lifetime.