On Fri, Aug 31, 2018 at 3:30 PM Daniel McCarney <c...@letsencrypt.org> wrote:
> here's a PR[0] for the Pebble ACME server that implements Richard's
>> proposal[1] to establish viability. The proposal seems OK to me given
>> the trade-offs/alternatives on the table.
>
>
> One of the changes Richard made in his second iteration of PR #445 was to
> differentiate a POST from a POST-as-GET by sending an empty body "a
> zero-length octet string" in the POST JWS. Talking about the experience of
> implementing this more with Jacob Hoffman-Andrews I think I've come around
> to preferring an alternative design. #445 as described requires server and
> client developers pay careful attention to the differences between `null`
> and `""` in serialization/deserialization and might be bumping into
> differences between languages/JSON parsers. Both myself and Jacob failed to
> get it right on a first-go[0] and if people this close to the specification
> are going to trip on this I think we can be assured others will too.
>
> A proposed alternative: We use `{}` as the body for POST-as-GET (as
> suggested by Jacob[1]) and further specify that challenges can only be
> initiated with a POST and do not support POST-as-GET.
>
> Using `{}` as the body matches the long standing method of authenticating
> access to account information and avoids any null troubles. Removing
> polling of challenges is required to free up POSTing `{}` as the challenge
> initiation message. All of the challenge information is already accessible
> by POST-as-GET polling the associated authorization and it seems sensible
> to remove that redundancy as it can cause bugs when a client developer
> polls a challenge for an authorization not realizing the associated
> authorization has changed to status valid from a different challenge.
>
> Thoughts?
>
The confusion over `null` and `""` is actually part of the motivation for
using a zero-length body -- it's not JSON. That's what makes it a good
signal. If you're doing POST-as-POST, you have a JSON body and you have to
do JSON stuff. If you're doing POST-as-GET, you're not and you don't. It
guarantees clean separation between the two cases, minimizing risk of
confusion.
I think the cleaner answer here is to fix the "account fetch" case to use
POST-as-GET.
--Richard
>
> [0] https://github.com/letsencrypt/pebble/pull/162#discussion_r214446189
> [1] https://github.com/ietf-wg-acme/acme/pull/445#issuecomment-417505743
>
> On Fri, Aug 31, 2018 at 2:56 PM, Daniel McCarney <c...@letsencrypt.org>
> wrote:
>
>> I think its an anti-pattern to standardize protocol features that haven't
>> been implemented by anyone so here's a PR[0] for the Pebble ACME server
>> that implements Richard's proposal[1] to establish viability. The proposal
>> seems
>> OK to me given the trade-offs/alternatives on the table.
>>
>> I would encourage other ACME client/server developers to try their hand
>> at implementing the changes from [1] as well. I've tested my PR with
>> hand-rolled requests but not as part of an automated issuance process with
>> a "real" ACME client. Speak now or forever hold your bugs.
>>
>> [0] - https://github.com/letsencrypt/pebble/pull/162
>> [1] - https://github.com/ietf-wg-acme/acme/pull/445/files
>>
>> On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes <r...@ipv.sx> wrote:
>>
>>> No, if a server receives a GET request for a resource other than those
>>> specified, then it MUST return 405. But please check out the PR and see if
>>> it's clear there.
>>>
>>> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich <rs...@akamai.com> wrote:
>>>
>>>>
>>>> - * Servers MUST return a 405 if they get a GET for a resource
>>>> other than directory/newNonce/certificate.
>>>>
>>>>
>>>>
>>>> They means client? Or there’s a word missing, and “they get a” is “they
>>>> do not support”
>>>>
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>>
>>
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
