Subject: [Acme] CAA Account Key Binding Draft Specification

From: Hugo Landau <[email-masked]>
Date: Thu, 14 Apr 2016 10:26:16 +0100

Alright, here's the first draft.

https://hlandau.github.io/draft-landau-acme-caa/

Hugo Landau

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Apr 2016 18:46:17 +0000

> https://hlandau.github.io/draft-landau-acme-caa/

Can others in the WG read this and make a suggestion as to yes/no adopt?  It's short (and the first para of 3.1 is a "did you read this" sentence fragment test? :)

Thanks!

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Apr 2016 11:50:21 -0700

Any reason not to publish this in the usual way? That will twig some folks
who look at the stream of published drafts.

Ted

On Wed, Apr 20, 2016 at 11:46 AM, Salz, Rich <[email-masked]> wrote:

> Can others in the WG read this and make a suggestion as to yes/no adopt?
> It's short (and the first para of 3.1 is a "did you read this" sentence
> fragment test? :)
>
> Thanks!
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 21 Apr 2016 04:02:11 +0900

> Can others in the WG read this and make a suggestion as to yes/no
> adopt?  It's short (and the first para of 3.1 is a "did you read this"
> sentence fragment test? :)

excuse?  i thought ietf wgs adopted internet-drafts not git repos.

randy

---

From: Hugo Landau <[email-masked]>
Date: Thu, 21 Apr 2016 20:45:30 +0100

Here we go:

https://datatracker.ietf.org/doc/draft-landau-acme-caa/

Hugo Landau

On Wed, Apr 20, 2016 at 11:50:21AM -0700, Ted Hardie wrote:
>    On Wed, Apr 20, 2016 at 11:46 AM, Salz, Rich <[1][email-masked]> wrote:
> 
>      > [2]https://hlandau.github.io/draft-landau-acme-caa/
> 
>      [3][email-masked]
>      [4]https://www.ietf.org/mailman/listinfo/acme
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]
>    2. https://hlandau.github.io/draft-landau-acme-caa/
>    3. mailto:[email-masked]
>    4. https://www.ietf.org/mailman/listinfo/acme

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Apr 2016 19:48:17 -0400

It is actually very important because those of us who spend their time
looking up patent prior art can't necessarily check the GitHub in 20
years time.

In some of the cases I have been involved in, the plaintiff has quite
literally read posts on an IETF mailing list and turned them into a
patent application.

---

From: Randy Bush <[email-masked]>
Date: Sat, 23 Apr 2016 12:06:11 +0900

> https://datatracker.ietf.org/doc/draft-landau-acme-caa/

thanks.  seems simple and makes sense.

randy, for adoption

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Apr 2016 10:49:30 -0400

Looks good to me.

I think it would also be useful to provide guidance to ACME clients as
to which CA to contact so as to support use of an LRA and/or
transition from one CA to another.

For example, lets say the initial CA was AliceCert.com and the site
decides to use BobCert.com instead. The site has to continue to post
AliceCert.com CAA records until all the issued certs have expired. But
the site wants all servers to make requests for new certs to
BobCert.com.

For any largish certificate deployment such as a house circa 2025 with
a hundred plus connected IoT devices, an LRA type approach is going to
be desirable. The consumer buys a doorbell, they want the doorbell to
use TLS and thus it needs a cert. They want all the certs in their
house to come from the same CA and be managed through one box.

For this particular type of application, we might well be looking at
an entirely new type of cert, something below DV in scope, possibly
not even a WebPKI cert at all. It might be a cert whose status is more
akin to a PGP subkey than what we have dealt with to date.

A CAA record is the natural place to put an entry to say 'go to here
to request a certificate'.

This is similar to the 'sufficient' issue that was discussed but I
don't think the same objection applies. I do not like the 'sufficient'
concept because in my world the CA can always reject a request for any
reason or no reason at all.