Subject: [Acme] IETF 97 follow-up PRs

From: Richard Barnes <[email-masked]>
Date: Sat, 19 Nov 2016 10:11:57 +0900

Hey ACME folks,

I've posted a few PRs implementing decisions made at the F2F:

#207 - Change agreementRequired to userActionRequired
https://github.com/ietf-wg-acme/acme/pull/207

#208 - Remove the 'requirements' abstraction
https://github.com/ietf-wg-acme/acme/pull/208

#209 - Add an external account binding field
https://github.com/ietf-wg-acme/acme/pull/209

#210 - Terminology update
https://github.com/ietf-wg-acme/acme/pull/210

(Note that #210 is based on top of #208, so the diff to master will look
bigger than it actually is until #208 lands.)

#211 - Add registries for fields in account and order objects
https://github.com/ietf-wg-acme/acme/pull/211

I would appreciate if you could put in any comments on these by Monday, Nov
28.

Chairs: I would like to make an editorial pass on the document this week,
but otherwise, once these land, I think the doc is ready for WGLC.

--Richard

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 23 Nov 2016 08:48:18 -0500

I added some minor editorial feedback on #207[0] and #208[1].

Thanks for collecting these up Richard!

[0] - https://github.com/ietf-wg-acme/acme/pull/207
[1] - https://github.com/ietf-wg-acme/acme/pull/208

On Fri, Nov 18, 2016 at 8:11 PM, Richard Barnes <[email-masked]> wrote:

> I would appreciate if you could put in any comments on these by Monday,
> Nov 28.
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 23 Nov 2016 09:59:08 -0500

PRs have been updated to address comments.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 28 Nov 2016 16:52:50 -0800

> https://github.com/ietf-wg-acme/acme/pull/207
LGTM
> https://github.com/ietf-wg-acme/acme/pull/208
Posted feedback:
https://github.com/ietf-wg-acme/acme/pull/208#pullrequestreview-10448372
> https://github.com/ietf-wg-acme/acme/pull/209
Seems fine, though this seems to have been superseded by #212. About
#212: Are we just reinventing OAuth here?
> https://github.com/ietf-wg-acme/acme/pull/210
LGTM
> https://github.com/ietf-wg-acme/acme/pull/211
LGTM

---

From: Richard Barnes <[email-masked]>
Date: Mon, 28 Nov 2016 21:37:40 -0500

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

Merged.

> https://github.com/ietf-wg-acme/acme/pull/208#pullrequestreview-10448372

To import that here so that we can have some discussion:
"""
I thought we were going to make this a simple array of URLs rather than
inlining the status (and therefore having it in two places)?
"""

I actually thought you were the one that suggested we keep the "status"
fields :)   The minutes not being dispositive, I pulled up the audio
recording of the meeting ([1], around 35:00), and didn't find anything
there either.  ¯\_(ツ)_/¯

I think it's worth keeping the status fields because even though it's a bit
more work for the server, it saves the client quite a bit of work in some
cases.  As I noted in the meeting, we recommend that CAs include all
authorizations that they used in their issuance decision -- even if they're
already valid.  (And I think that's an important property to keep, for
clarity.)  Putting the status field in the order saves the client the work
of sending a pile of GET requests for these already-valid authorizations.

Can you live with that level of duplication, given the client ergonomics
benefit?

> Seems fine, though this seems to have been superseded by #212.

Agreed.  Since nobody seems to have strong objections to #212, closing this
one.

> About #212: Are we just reinventing OAuth here?
>

In brief, no.  OAuth is a whole pile of specs that interact in complicated
ways, and include a lot of stuff we don't need.  OAuth also doesn't provide
the delegation semantics we need here.  So we're re-using the relevant part
of OAuth (namely JWS), and not importing a lot of irrelevant stuff.

Unless you have strong objections, I think we should go ahead and merge
#212, since everyone else on the list seems to be OK with it.

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

Merged.

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

Merged.

[1] https://www.ietf.org/audio/ietf97/ietf97-studio4-20161116-1330.mp3

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Nov 2016 13:52:32 +1100

On 29 November 2016 at 13:37, Richard Barnes <[email-masked]> wrote:
> recording of the meeting ([1], around 35:00), and didn't find anything there
> either.  ¯\_(ツ)_/¯

FWIW, I remember you mentioning that you would like to retain the
status fields, but it might have been non-verbal communication that
indicated assent.

Both approaches have their merits: either pick simplicity, or make the
extra information available where it is immediately useful.  As you
say, there's a pretty big saving if status is there.  A client then
only has to act on unresolved challenges.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 29 Nov 2016 11:26:19 -0800

On 11/28/2016 06:37 PM, Richard Barnes wrote:
> I actually thought you were the one that suggested we keep the
> "status" fields

Nope, I have always been in favor of not inlining the status fields. We
talked about this directly, but also it was in my previous PR and thread
about merging requirements and authorizations:

>> 3. "Inline" the authorization objects into the order/application
object, just as challenges are inlined into authorizations (while
still keeping them addressable, as challenges are)

> I don't see the need for this, and actually think it's a negative. GETs
are cheap for the client, especially with HTTP/2. Inlining like this
means there are two ways for a client to check the status of an
authorization: by polling the authz, or by polling the application /
order. We've seen in Boulder that having two ways to do things leads to
bugs, so I'd rather say you must poll the authorization.

> Also, for orders with lots of authz's in them, polling the order object
will be more expensive for the server than polling individual authzs,
because each poll of the order object has to reconstruct a larger number
of objects from the DB. When clients poll individual authzs, they only
check each authz until it is done, then stop.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Nov 2016 15:37:12 -0500

> check each authz until it is done, then stop.

I can live with that.  I'll update the PR.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Nov 2016 16:00:23 -0500

Updated:

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 29 Nov 2016 13:01:30 -0800

LGTM

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Nov 2016 16:05:56 -0500

Could you please click the button on GH to indicate that? :)