Subject: [Acme] I-D Action: draft-ietf-acme-ip-02.txt

From: [email-masked]
Date: Fri, 18 May 2018 12:49:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment WG of the IETF.

        Title           : ACME IP Identifier Validation Extension
        Author          : Roland Bracewell Shoemaker
	Filename        : draft-ietf-acme-ip-02.txt
	Pages           : 4
	Date            : 2018-05-18

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for IP addresses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-ip/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-ip-02
https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-ip-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Roland Shoemaker <[email-masked]>
Date: Fri, 18 May 2018 15:16:32 -0700

Sorry for the lag on getting this out. Given the discussions at IETF 101 and on the list the main change in this version is the removal of the reverse-dns challenge type. While I still think there is some value in at least having a technical definition of the method there is enough opposition that it’s inclusion in this draft would’ve stopped any forward progress in its tracks. Otherwise there are a few minor editorial changes but not much else.

> On May 18, 2018, at 12:49 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 19 May 2018 14:58:01 +0300

On Fri, May 18, 2018 at 03:16:32PM -0700, Roland Shoemaker wrote:
> Sorry for the lag on getting this out. Given the discussions at IETF
> 101 and on the list the main change in this version is the removal of
> the reverse-dns challenge type. While I still think there is some value
> in at least having a technical definition of the method there is enough
> opposition that it’s inclusion in this draft would’ve stopped any
> forward progress in its tracks. Otherwise there are a few minor editorial
> changes but not much else.

I note that TLS-SNI-02 is still there. But that method has gotten ripped
out from the main ACME spec due to security problems.

-Ilari

---

From: Roland Shoemaker <[email-masked]>
Date: Mon, 21 May 2018 11:55:09 -0700

Ah, yup, good catch. I totally spaced we’d pulled that out.

Likely we’ll want to reference TLS-ALPN here but it kind of ends up being a chicken and egg scenario. If draft-ietf-acme-tls-alpn gets standardized first we’ll want to mention that in this document updating it’s method to accept IPs, if we standardize draft-ietf-acme-ip first we’ll want to mention in draft-ietf-acme-tls-alpn that it can work with IP identifiers.

It seems like there is more forward momentum on draft-ietf-acme-tls-alpn so I suspect we should just wait for that to be done to get this out the door… thoughts?

> On May 19, 2018, at 4:58 AM, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 21 May 2018 12:38:38 -0700

> It seems like there is more forward momentum on draft-ietf-acme-tls-alpn so I suspect we should just wait for that to be done to get this out the door… thoughts?
Let's continue to work on the IP draft with the assumption that 
something named tls-alpn will land, with the goal to land them both 
around the same time. In the unlikely event the IP draft is ready to 
finalize before tls-alpn is, we can choose then to either hold it up, or 
remove the reference to tls-alpn. I'd like to avoid coupling things as 
much as possible since that's a surefire way to slow progress.