Subject: Re: [Acme] Post-IETF-96 PRs

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Aug 2016 15:22:10 -0400

Two more:

#165 - Re-add new-authz as pre-authorization
https://github.com/ietf-wg-acme/acme/pull/165

#166 - Clarify 'url' field processing
https://github.com/ietf-wg-acme/acme/pull/166

On Thu, Jul 28, 2016 at 5:52 PM, Richard Barnes <[email-masked]> wrote:

> Hey all,
>
> I just posted several PRs implementing agreements from the IETF meeting.
>
> #161 - Drop the OOB challenge
> https://github.com/ietf-wg-acme/acme/pull/161
>
> #162 - Add a protocol version
> https://github.com/ietf-wg-acme/acme/pull/162
>
> #163 - Make duplicate new-reg return 303
> https://github.com/ietf-wg-acme/acme/pull/163
>
> (NB: I used 303 instead of 302 because I thought it was a better fit after
> reading the HTTP spec.  Nothing is going to be a perfect fit here.)
> https://tools.ietf.org/html/rfc7231#section-6.4.4
>
> Please send feedback on these to the list.  If I don't hear anything back
> by late next week, I'll start merging.
>
> Thanks,
> --Richard
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 6 Aug 2016 10:46:45 -0700

> https://github.com/ietf-wg-acme/acme/pull/165
Gave feedback on a separate thread.
> https://github.com/ietf-wg-acme/acme/pull/166
LGTM
>     <https://github.com/ietf-wg-acme/acme/pull/161>
>
LGTM
>     <https://github.com/ietf-wg-acme/acme/pull/162>
>
Still thinking about this one. Seems sound at first glance, but I'm
thinking about TLS version intolerance and
https://www.imperialviolet.org/2016/05/16/agility.html.

>     <https://github.com/ietf-wg-acme/acme/pull/163>
>
>     (NB: I used 303 instead of 302 because I thought it was a better
>     fit after reading the HTTP spec.  Nothing is going to be a perfect
>     fit here.)
>     <https://tools.ietf.org/html/rfc7231#section-6.4.4>
>
Agreed that nothing is a perfect fit here. In particular, common UA
behavior is to turn a POST into a GET, which will fail because you can't
GET a registration. However, we also don't want the UA to re-POST,
because (a) the nonce will be used up already, and (b) the POST for a
new-reg isn't the same as a POST for an existing registration.

Can you provide more detail on the motivation for this change, both
on-list and in the PR description?

---

From: Richard Barnes <[email-masked]>
Date: Sat, 6 Aug 2016 14:23:07 -0400

On Sat, Aug 6, 2016 at 1:46 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> thinking about TLS version intolerance and https://www.imperialviolet.
> org/2016/05/16/agility.html.
>
> GET a registration. However, we also don't want the UA to re-POST, because
> (a) the nonce will be used up already, and (b) the POST for a new-reg isn't
> the same as a POST for an existing registration.
>

I think the motivation is pretty clearly spelled out in the corresponding
issue:
https://github.com/ietf-wg-acme/acme/issues/157

In brief, the idea is that this is not an error condition, so it shouldn't
use an error status (4xx / 5xx).  Now we're just haggling over which code
to use.

I would note that the most recent version of the spec to have new-authz
also used 303 when it found an existing authz.  So wherever we end up, we
should be consistent between those two cases.

As far as 3XX (your argument is not specific to 303) -- it seems like the
POST->GET change is only an issue for libraries that automatically follow
redirects, which I don't think is a universal behavior.  But I would be
open to returning a 2XX if we could find a good one.  Probably would want
to send Content-Location for the URL.

--Richard

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 6 Aug 2016 11:33:36 -0700

> I would note that the most recent version of the spec to have
> new-authz also used 303 when it found an existing authz.  So wherever
> we end up, we should be consistent between those two cases.
Good point.
>
> As far as 3XX (your argument is not specific to 303) -- it seems like
> the POST->GET change is only an issue for libraries that automatically
> follow redirects, which I don't think is a universal behavior.
It's not universal behavior, but it may preclude implementation with
some libraries. It would be good to have more data on this front. Any
chance you have time to test, e.g. XHR, Python requests library, and
Node requests library?

>   But I would be open to returning a 2XX if we could find a good one. 
> Probably would want to send Content-Location for the URL.
I'm leaning towards 200 on these, but still willing to be convinced.

---

From: Peter Bowen <[email-masked]>
Date: Sat, 6 Aug 2016 12:57:32 -0700

> https://github.com/ietf-wg-acme/acme/pull/161

I'm interested in the rationale for dropping the OOB challenge.  As it
stands, the OOB challenge can be used to indicate that a given domain
name (or namespace) is authorized.  This would seem to have value for
existing CAs who want to offer some level of ACME compatibility but
might not be able to make the whole pure-ACME workflow operate in
their system.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 12:28:53 +1000

On 7 August 2016 at 03:46, Jacob Hoffman-Andrews <[email-masked]> wrote:
> Still thinking about this one. Seems sound at first glance, but I'm thinking
> about TLS version intolerance and

For similar reasons, I think that this change might be a little
overwrought.  It's certainly a non-trivial amount of added complexity.

Would it be acceptable to have a much simpler scheme that included the
version (a simple string that has to match) in the payload of all
messages?  That keeps this as a sanity check that you aren't
transporting things between incompatible versions.  The server can
provide new endpoints if it wants to support new (incompatible)
versions.

---

From: Richard Barnes <[email-masked]>
Date: Sun, 7 Aug 2016 19:32:17 -0700

> might not be able to make the whole pure-ACME workflow operate in

Yeah, I noted this at the mic in IETF 96, and it just sort of got shrugs on
both sides.  I don't think anyone is calling real strongly for it to be
pulled out, so if you think it's useful, I'm happy to leave it.

---

From: Richard Barnes <[email-masked]>
Date: Sun, 7 Aug 2016 19:39:41 -0700

> overwrought.  It's certainly a non-trivial amount of added complexity.

Overwrought, indeed.  It certainly felt that way while writing it, but
that's where the line of thinking seemed to lead me.

Maybe it's worthwhile stepping back and asking what sorts of changes we
might want to make, and how those should be done.

Within the framework we have right now, you can already add new
functionality by adding resources or fields on objects.  If you want to
require the new functionality, you can add error codes to cleanly fail old
clients.  And if you want to do something totally different, you can change
the directory URL.

So I'm honestly not that convinced that we need versioning at all here.
Maybe we could get away with just versioning the directory?  (As I think
the original issue proposed :) )

--Richard

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 13:29:54 +1000

On 8 August 2016 at 12:39, Richard Barnes <[email-masked]> wrote:
> Maybe we could get away with just versioning the directory?  (As I think the
> original issue proposed :) )

I believe that it was PHB who requested this originally, the rationale
being that you might create a new version of the same resource/request
that looked similar, but had different semantics.  Rather than rely on
having us (in all our possible future incarnations) not doing that, a
version indicator would make signatures invalid.

If that is a requirement that you accept, then a much simpler scheme
than the one you wrote up is possible.  Versioning the directory isn't
sufficient to achieve that goal though.  The first part of your PR
would work though: include a version, and require that it be checked.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Aug 2016 09:53:07 -0700

> would work though: include a version, and require that it be checked.

Looking at the minutes from Berlin...

"RLB: do we need both server and client versions? MT: sure"

:)

I'm not sure we can get away without any server versioning.  The server
needs some way to signal support, even if it's only in an error message.

Again, I'm not totally convinced that semantic mismatches are that big a
deal.  The "url" parameter already scopes the signed object to a specific
resource, so the only risk would be if that specific resource accepts
different object formats that are confusable with one another.  You need
some signal to disambiguate, but it's not clear to me that having one big
version is the best solution.

--Richard

---

From: Ron <[email-masked]>
Date: Tue, 9 Aug 2016 03:42:20 +0930

> version is the best solution.

FWIW, we did have that situation when the "delete":true flag was added
to the -02 "resource":"reg" object - in that Boulder 'successfully' did
something quite different by not implementing that flag if a client
tried to use it ...

But I do agree that sort of thing can be mitigated with some careful
thought about whether we can safely ever extend objects like that or
not.  And if we can't, by implementing a new object or resource that
does have the desired semantics.

This is JSON, we can trivially rename things in expressive ways if
needed.  Unlike a bit-starved binary format where you could only spare
a few bits for a 'version number' to tell you that the otherwise
unlabelled byte 4 still means what you previously thought it did.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 12:03:10 +1000

> version is the best solution.

Let's not overwork this one, I don't care that much either way on this
point.  The suggestion seemed to have a low complexity cost for some
gain.  That cost doesn't seem to be as low as first expected
(surprise!).  Thus, I'm not willing to spend too much extra effort to
keep this.

---

From: Roland Shoemaker <[email-masked]>
Date: Tue, 9 Aug 2016 14:22:14 -0700

>From the view point of Let's Encrypt/Boulder: Our original plan for
major specification changes has been to provide multiple versioned API
endpoints which implement different verions of ACME. Currently we only
provide acme-v01.api.letsencrypt.org which implements an amalgam of the
first four drafts (documented here:
https://github.com/letsencrypt/boulder/blob/243832822a28e04e46dc26ab3554ac2062731cc6/docs/acme-divergences.md)
but given the number of breaking/major flow changes in draft-03 we plan
to make a second endpoint available (presumably acme-v02) which will be
a strict implementation of the specification once it is finalized.

Assuming, given the recent discussion of entering WGLC, that the
specification is in the process of stabilizing and that the largest
server side implementer most likely won't implement large portions of
the new spec until it is finalized adding fine grained versioning to the
protocol seems like overkill.

I'm not entirely convinced the specification itself needs to provide a
versioning mechanism at all beyond perhaps indicating that if a server
chooses to implement an older version of the specification it should do
so on a distinct endpoint.

On 08/08/2016 07:03 PM, Martin Thomson wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>