Subject: [Acme] Draft agenda timing

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Mar 2015 13:33:50 -0800

Rich and I are thinking of this as the breakdown of how we'd spend the hour
we have; comments welcome.

ACME BOF
IETF 92
Time: Wednesday, March 25, 2015 1520-1620​
​Location: Venetian Room​

​Administrivia: 5​
Motivating requirements: 10
​Possible additional requirements from industry​: 10
Review of draft-barnes-acme: 15
Discussion: 20

regards,

Ted and Rich

---

From: "Songhaibin (A)" <[email-masked]>
Date: Mon, 9 Mar 2015 03:08:53 +0000

Both ETSI NFV community and ONF SDN community are working on certificate management, and they also want automated certificate management to the VNF or logical/physical switches. I think although in draft-barnes-acme DV (domain validation) is the initial use case for ACME to address, NFV/SDN certificate management could be the next step. They need a different way to challenge the certificate requester.

Best Regards!
-Haibin

From: Acme [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Saturday, March 07, 2015 5:34 AM
To: [email-masked]; Salz, Rich
Subject: [Acme] Draft agenda timing

Rich and I are thinking of this as the breakdown of how we'd spend the hour we have; comments welcome.
ACME BOF
IETF 92
Time: Wednesday, March 25, 2015 1520-1620​
​Location: Venetian Room​

​Administrivia: 5​

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 09 Mar 2015 06:59:39 +0100

> Both ETSI NFV community and ONF SDN community are working on certificate management, and they also want automated certificate management to the VNF or logical/physical switches. I think although in…

I guess one major difference is (or should be) that network devices are identified by a device certificate rather than a domain.
Such devices may also provide end-to-end security through attestation keys.

Anyway, there is another big use-case as well and that is providing mobile devices with credentials for authentication, payments etc.
This is my line of work.

Unfortunately I won't be at the IETF meeting.

Anders

> Best Regards!
>
> -Haibin
>
> *From:*Acme [mailto:[email-masked]] *On Behalf Of *Ted Hardie
> *Sent:* Saturday, March 07, 2015 5:34 AM
> *To:* [email-masked]; Salz, Rich
> *Subject:* [Acme] Draft agenda timing
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Mar 2015 15:27:59 +0000

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.

	/r$
--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Mar 2015 15:39:11 +0000

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

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.

Cheers,
S.

> 
> /r$ -- Senior Architect, Akamai Technologies IM: [email-masked]
> Twitter: RichSalz
> 
> _______________________________________________ Acme mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/acme
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Mar 2015 12:50:59 -0400

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