Subject: [Acme] Challenge names in final RFC

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 13 Mar 2017 11:26:30 -0700

Roland posted a PR tweaking the challenge names for the final RFC:
https://github.com/ietf-wg-acme/acme/pull/272.

This raised the question: What do we want the challenge names to be in
the final RFC? I think we've been assuming that "http-01" would become
"http" once the RFC is published. However, this does create a slightly
deployment headache, in that draft-compatible implementations have to
use one name, and RFC-compatible implementations have to use another, so
it's hard to test working code with the final names before the RFC is
really finalized.

I don't have a strong opinion on this one way or another. What do folks
on this list think?

---

From: Richard Barnes <[email-masked]>
Date: Mon, 13 Mar 2017 14:56:45 -0400

I would prefer we stick with dropping the version number, just because it's
cleaner and the future is bigger than the past.

On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Roland Shoemaker <[email-masked]>
Date: Mon, 13 Mar 2017 21:28:50 -0700

I'd argue that removing the challenge version numbers adds unnecessary
complexity to the specification and any existing implementations going
forward.

Existing servers and clients will need to have some kind of mapping from
the draft names to the final un-versioned names and any protocol
revisions going forward will need to know about both the versioned and
un-versioned names so that they don't name a new version of a challenge
using one of the draft version numbers, leading to existing
implementations thinking an older version is actually being used.

I agree dropping the version numbers is somewhat more aesthetically
pleasing but I can't really see any actual technical reasons to do so,
while keeping them seems like it'd save a lot of headaches down the road.

On 03/13/2017 11:56 AM, Richard Barnes wrote:
> I would prefer we stick with dropping the version number, just because
> it's cleaner and the future is bigger than the past.  
> 
> 
> On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     https://github.com/ietf-wg-acme/acme/pull/272
>     <https://github.com/ietf-wg-acme/acme/pull/272>.
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
> 

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Mar 2017 15:53:59 +1100

Consider this a dry run for eventually rolling out variants that use
SHA-3-?? instead of SHA-256.  The code for aliasing should give you
confidence that you can ship new challenges without disrupting
usability.

In a way, it's a shame that the challenges didn't change more often
during development.  Testing concurrent support for old and new
versions is pretty valuable.

---

From: Alan Doherty <[email-masked]>
Date: Tue, 14 Mar 2017 06:26:41 +0000

+1

---

From: Brad Warren <[email-masked]>
Date: Tue, 21 Mar 2017 12:07:27 -0700

After talking about this with the rest of the Certbot team, we agree
with Roland as well. While certainly either approach is doable, dropping
the version number adds additional complexity for the many dozens of
existing implementations for no real technical benefit.