Subject: Re: [Acme] PRs for unparallelization and new-nonce

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Sep 2016 13:05:36 -0400

These three (#164, #181, #185) have now been merged.

On Fri, Aug 26, 2016 at 11:04 PM, Richard Barnes <[email-masked]> wrote:

> One more, pretty trivial one, but throwing it out there in case people
> have bike shed paint they want to use:
>
> #185 - Change 'url' field on OOB challenge to 'href'
> https://github.com/ietf-wg-acme/acme/pull/185
>
> I noticed as I was implementing the oob-01 challenge that in the current
> spec, there are both "uri" and "url" fields, which seemed destined to lead
> to confusion.  So this PR changes the "url" field to "href", as in <a
> href="...">.
>
>
> On Fri, Aug 26, 2016 at 1:16 PM, Richard Barnes <[email-masked]> wrote:
>
>> Hey all,
>>
>> Going through PRs today, trying to see where we can make progress.  I've
>> already merged several that seemed non-controversial [1].  There are two
>> more where I think we have agreement, but I wanted to give people a few
>> days to opine:
>>
>> ---
>> #181 - Add a new-nonce endpoint
>> https://github.com/ietf-wg-acme/acme/pull/181
>>
>> This was proposed by Jacob as a resolution to the tension between nonces
>> and cacheability (raised in #156).  I also like this as a solution, so I
>> went ahead and implemented it.
>>
>> ---
>> #164 - Unparallelize signatures on key-change
>> https://github.com/ietf-wg-acme/acme/pull/164
>>
>> We've wandered a little bit in the discussion of this PR, but there seems
>> to be agreement on the main points:
>> * Use nested rather than parallel signatures
>> * Use JWKs rather than thumbprints to represent the keys
>> * Require the "url" parameter to be the same for both inner and outer JWSs
>> * No requirement on the nonce parameter in the inner JWS
>>
>> The main remaining conflict is about the general question of whether we
>> should represent accounts by key, URL, or both.  That's a more general
>> question than this PR, though, so I'm going to propose we go ahead and make
>> the changes we've agreed on, and if we change the representation of
>> accounts later, we can update this section to match.
>>
>> I've updated the PR to reflect the above agreements, and added a JWK
>> equivalence test that I think should be agreeable to everyone.
>>
>> ---
>>
>> I would appreciate if people could take a quick look at these and
>> thumbs-up/down.  If I don't hear objections by mid-next-week, I'll go ahead
>> and merge.
>>
>> --Richard
>>
>> [1]
>> #163 - Make duplicate new-reg return 200
>> #166 - Clarify 'url' field processing
>> #171 - Remove combinations array
>> #175 - Remove certificates field from registration object
>> #176 - Fix typos
>> #178 - Fixes two typos not addressed by #176
>> #179 - Clarify "new-X" resources paragraph
>>
>>
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 8 Sep 2016 15:15:13 -0700

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

LGTM

> We've wandered a little bit in the discussion of this PR, but there
> seems to be agreement on the main points:

LGTM, thanks for working through this. I have a small editorial fix as a
followup: https://github.com/ietf-wg-acme/acme/pull/187/files.

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

LGTM

> #179 - Clarify "new-X" resources paragraph

LGTM

---

From: Niklas Keller <[email-masked]>
Date: Fri, 9 Sep 2016 08:21:58 +0200

The following PR has been merged:

> > #163 - Make duplicate new-reg return 200

It should return a status code 200 now and the URI in a content-location
header.

I have two questions:

   1. Should we reallly use "Content-Location" instead of simply "Location"?
   2. What's the response body? The registration object? Is it empty?

I think "Content-Location" makes sense if we return the registration
object, on the other hand "Location" is more consistent with the 201
response.

Regards, Niklas