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. On 14 March 2017 at 15:28, Roland Shoemaker <[email protected]> wrote: > 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 protected] >> <mailto:[email protected]>> wrote: >> >> Roland posted a PR tweaking the challenge names for the final RFC: >> https://github.com/ietf-wg-acme/acme/pull/272 >> <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? >> >> _______________________________________________ >> Acme mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/acme >> <https://www.ietf.org/mailman/listinfo/acme> >> >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > > -- > Roland Bracewell Shoemaker > Software Engineer > Linux Foundation / Internet Security Research Group > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
