Re: [Acme] Draft agenda timing

Phillip Hallam-Baker <> Mon, 09 March 2015 16:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D315C1A9040 for <>; Mon, 9 Mar 2015 09:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N0GvyKONLHPi for <>; Mon, 9 Mar 2015 09:51:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0A071A8F4B for <>; Mon, 9 Mar 2015 09:51:00 -0700 (PDT)
Received: by labgm9 with SMTP id gm9so2988059lab.11 for <>; Mon, 09 Mar 2015 09:50:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id y5mr26079176lbw.91.1425919859474; Mon, 09 Mar 2015 09:50:59 -0700 (PDT)
Received: by with HTTP; Mon, 9 Mar 2015 09:50:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 9 Mar 2015 12:50:59 -0400
X-Google-Sender-Auth: mXQ2sZwmcJRZ6RvQ7QlXmQ-hgc4
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary=001a11c3bb70b3c82c0510ddd6c1
Archived-At: <>
Cc: "Salz, Rich" <>, "Songhaibin \(A\)" <>, "" <>, Ted Hardie <>, Anders Rundgren <>
Subject: Re: [Acme] Draft agenda timing
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2015 16:51:10 -0000

On Mon, Mar 9, 2015 at 11:39 AM, Stephen Farrell <>

> 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

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...