Re: [Acme] Draft agenda timing

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 09 March 2015 16:51 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 D315C1A9040 for <acme@ietfa.amsl.com>; Mon, 9 Mar 2015 09:51:09 -0700 (PDT)
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 N0GvyKONLHPi for <acme@ietfa.amsl.com>; Mon, 9 Mar 2015 09:51:08 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 F0A071A8F4B for <acme@ietf.org>; Mon, 9 Mar 2015 09:51:00 -0700 (PDT)
Received: by labgm9 with SMTP id gm9so2988059lab.11 for <acme@ietf.org>; Mon, 09 Mar 2015 09:50:59 -0700 (PDT)
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=EVfrOfnVN1fLcFL7Ps2sbYh/eowmct89bRyckVYBkek=; b=it1oRphqja+GhFr+biohTbtAr9jntT91Nhklrmk2JmAkTEHa9YzvUhY2aH+H1MN4S2 UJyfy8CgEJKqEC5nvxKtilRUvs2MKd/AO0AkCGA6O16P/LYmzwd8iqrE0ZIdZ7YuX7lw YfHoPZ5QAStn/gUNZmwwXT/Hp1UJ2u5Hhj0oF9h0kasJl9N7XknpeqQD7pKQ2llDUN5g 3kcWOgvEIwogzp+qrlvN93YDlM4cgb0vv2uv38YphDGYcPXLD0KWMQRH3Fo44FkNYGx4 PdcYQJKr6boGekPF8yRTfsk7H1RHJFExBpf1PyxQtVMATkGrlDUDr2c45do/FBumujV0 4nzg==
MIME-Version: 1.0
X-Received: by 10.112.78.37 with SMTP id y5mr26079176lbw.91.1425919859474; Mon, 09 Mar 2015 09:50:59 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.45.203 with HTTP; Mon, 9 Mar 2015 09:50:59 -0700 (PDT)
In-Reply-To: <54FDBE9F.4040807@cs.tcd.ie>
References: <CA+9kkMBzrr6=7TtTrOHTCXQA6WKdCHvTEiLFjx252pv2xuASNg@mail.gmail.com> <E33E01DFD5BEA24B9F3F18671078951F65246E87@nkgeml501-mbs.china.huawei.com> <54FD36CB.1060607@gmail.com> <b3e2e8a398a0497184762b1b093379e7@usma1ex-dag1mb2.msg.corp.akamai.com> <54FDBE9F.4040807@cs.tcd.ie>
Date: Mon, 9 Mar 2015 12:50:59 -0400
X-Google-Sender-Auth: mXQ2sZwmcJRZ6RvQ7QlXmQ-hgc4
Message-ID: <CAMm+Lwh3gPOmraF44gDAN7ZpGb3U4+cocpy2mwCNbZkTT0bgSw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a11c3bb70b3c82c0510ddd6c1
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/hPao2Nwu3_JV_IxijmVs4bHP8Q8>
Cc: "Salz, Rich" <rsalz@akamai.com>, "Songhaibin \(A\)" <haibin.song@huawei.com>, "acme@ietf.org" <acme@ietf.org>, Ted Hardie <ted.ietf@gmail.com>, Anders Rundgren <anders.rundgren.net@gmail.com>
Subject: Re: [Acme] Draft agenda timing
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: Mon, 09 Mar 2015 16:51:10 -0000

On Mon, Mar 9, 2015 at 11:39 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 09/03/15 15:27, Salz, Rich wrote:
> > Our main goal is not to handle all certificate enrollment use-cases,
> > but rather focus on "I want to secure my website."  We expect that
> > there will be things we can do to the base I-D to make it more
> > amenable to future expansion to handle NFV/SDN down the line.  Or
> > that those communities could an enhanced protocol as a starting
> > point.
> >
> > But enumerating some of the requirements seems to make sense in the
> > "additional requirements" agenda item.
>
> Right.
>
> Accumulating use-cases is a fine thing to do. But, and it's a BIG
> but, those additional use cases are only of interest if they don't
> deflect or distract from meeting the primary goals of this work.
> (Which the BoF and list determine of course.)
>
> The IETF has messed up certificate management sufficiently often
> that as an AD, (and as a past participant in messing this up;-),
> I'll not be sponsoring work that I think is overly broad or that
> lacks a laser-like focus on getting one or a few things done and
> done well enough to see useful deployment.



I don't think that is going to be a problem in this case.

The concern for the requirements in my view is that we don't end up
painting ourselves into a corner with some assumption in the base spec.

For example, don't assume that the CA can give an immediate yes/no response
without any human interaction ever. Even with a DV cert there is a
requirement to check for certain look-alike names. Don't assume that the
key will be generated in a particular way or at a particular location
either.

Until we move away from RSA, I do not want my cloud based web servers
generating their own private key pairs on a machine the attacker could rent
space on. I don't want the servers having one year certs either...


So long as the protocol is in JSON and we don't have statements of the form
X MUST <do something that assumes something that isn't necessarily the
case>. I think we are OK.


We didn't just mess it up in IETF either...