>
> 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?
[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
