Re: [Acme] Draft agenda timing

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 09 March 2015 16:51 UTC

MIME-Version: 1.0
Sender: hallam@gmail.com
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, 09 Mar 2015 12:50:59 -0400
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
Precedence: list

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

[Acme] Draft agenda timing Ted Hardie
Re: [Acme] Draft agenda timing Songhaibin (A)
Re: [Acme] Draft agenda timing Anders Rundgren
Re: [Acme] Draft agenda timing Salz, Rich
Re: [Acme] Draft agenda timing Stephen Farrell
Re: [Acme] Draft agenda timing Phillip Hallam-Baker