Re: [Acme] POST-as-GET payload contents

[Tim Hollebeek]

I agree “” is better than “{}”.

 

-Tim

 

From: Acme  On Behalf Of Richard Barnes
Sent: Wednesday, September 5, 2018 4:11 PM
To: Jacob Hoffman-Andrews 
Cc: Logan Widick ; IETF ACME 
Subject: Re: [Acme] POST-as-GET payload contents

 

 

On Wed, Sep 5, 2018 at 3:43 PM Jacob Hoffman-Andrews mailto:j...@eff.org> > wrote:

On 09/05/2018 12:39 PM, Richard Barnes wrote:
> Using the same notation, I'm:
>
> 1) ""
> 2) "urn:ietf:params:acme:get"
> 99) "{}"

Given that, I'm willing to compromise on "". I think the experience we 
had of almost implementing bugs with that approach was informative, but 
isn't decisive.

 

Thanks for compromising.  I agree that the interop stuff will cause some 
hiccups, but hopeful that rather than being a blocker for folks, it will create 
some pressure for JOSE libraries to interop better in this case.  In any case, 
I'll update the PR to make extra clear that {payload: ""} is what's required.

 

Anyone else have opinions before we consider this closed?

 

--Richard

 



smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

On Wed, Sep 5, 2018 at 3:43 PM Jacob Hoffman-Andrews  wrote:

> On 09/05/2018 12:39 PM, Richard Barnes wrote:
> > Using the same notation, I'm:
> >
> > 1) ""
> > 2) "urn:ietf:params:acme:get"
> > 99) "{}"
>
> Given that, I'm willing to compromise on "". I think the experience we
> had of almost implementing bugs with that approach was informative, but
> isn't decisive.
>

Thanks for compromising.  I agree that the interop stuff will cause some
hiccups, but hopeful that rather than being a blocker for folks, it will
create some pressure for JOSE libraries to interop better in this case.  In
any case, I'll update the PR to make extra clear that {payload: ""} is
what's required.

Anyone else have opinions before we consider this closed?

--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Jacob Hoffman-Andrews]

On 09/05/2018 12:39 PM, Richard Barnes wrote:

Using the same notation, I'm:

1) ""
2) "urn:ietf:params:acme:get"
99) "{}"


Given that, I'm willing to compromise on "". I think the experience we 
had of almost implementing bugs with that approach was informative, but 
isn't decisive.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

Using the same notation, I'm:

1) ""
2) "urn:ietf:params:acme:get"
99) "{}"

The problem with "{}" is not just what it conflicts with in the current
doc, it's that it constrains everything one might do in the future.  Same
with any other payload-only option (including {"get": true}) with valid
JSON payload.  So your options are (1) do something in the protected header
or (2) have the payload be something non-JSON.

If you want something payload-only that is not empty, that seems doable as
well.  We could require the payload to be the two-octet string 0x1844,
which conveniently base64url-encodes to "GET" :)

On Wed, Sep 5, 2018 at 1:17 PM Jacob Hoffman-Andrews  wrote:

> On 09/05/2018 08:33 AM, Richard Barnes wrote:
> > 1. A field in the protected header ("urn:ietf:params:acme:get": true)
> > with a requirement that the payload be "{}"
> > 2. A field in the payload ({"get": true}) a requirement that if that
> > field be there, then there are no other fields present
>
> I dislike both of these options as adding complexity. My preference
> order is:
>
> 1) "{}"
> 2) ""
> 99) "urn:ietf:params:acme:get"
>
>  > I'm still uncomfortable with {}, though, because it risks colliding
> with other POST uses.
>
> The only current use it conflicts with is POSTing to challenges to
> trigger their validation. We can fix that two ways:
>
>   - Define challenges as non-pollable: Poll authorizations instead,
> since they contain the challenges. This was something I'd proposed
> previously, in the spirit of "there should just be one way to do
> things." Right now, some clients poll authorizations and some poll
> challenges. There's no benefit to one way or the other, it's just a
> random implementer choice that sometimes exposes different code paths.
>
>   - Define multiple POSTs to challenges as idempotent. That is, the
> first time you POST a "{}" body to a challenge it triggers validation,
> and subsequently it acts as a GET.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Eric Rescorla]

On Wed, Sep 5, 2018 at 9:53 AM, Salz, Rich <
rsalz=40akamai@dmarc.ietf.org> wrote:

>
>- Because being generous in what you receive is harmful.
>
> https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
> 
>
>
>
> Sorry, I disagree with King Martin in this case. :)
>

I think he's still Prince Martin :)

-Ekr


>
> I think mandating a specific requrest body is hard to get right.
>
> ___
> 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

Re: [Acme] POST-as-GET payload contents

[Jacob Hoffman-Andrews]

On 09/05/2018 08:33 AM, Richard Barnes wrote:
1. A field in the protected header ("urn:ietf:params:acme:get": true) 
with a requirement that the payload be "{}"
2. A field in the payload ({"get": true}) a requirement that if that 
field be there, then there are no other fields present


I dislike both of these options as adding complexity. My preference 
order is:


1) "{}"
2) ""
99) "urn:ietf:params:acme:get"

> I'm still uncomfortable with {}, though, because it risks colliding 
with other POST uses.


The only current use it conflicts with is POSTing to challenges to 
trigger their validation. We can fix that two ways:


 - Define challenges as non-pollable: Poll authorizations instead, 
since they contain the challenges. This was something I'd proposed 
previously, in the spirit of "there should just be one way to do 
things." Right now, some clients poll authorizations and some poll 
challenges. There's no benefit to one way or the other, it's just a 
random implementer choice that sometimes exposes different code paths.


 - Define multiple POSTs to challenges as idempotent. That is, the 
first time you POST a "{}" body to a challenge it triggers validation, 
and subsequently it acts as a GET.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Salz, Rich]

  *   Can you point to an implementation framework where this would be 
difficult?  AFAIK, every JSON library out there marshalls {} as "{}", with no 
whitespace, and every JOSE library signs whatever string you give it.

You know more than I do.  If it’s not an issue, okay.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Daniel McCarney]

>
> AFAIK, every JSON library out there marshalls {} as "{}", with no
> whitespace, and every JOSE library signs whatever string you give it.


I agree, I don't think the {} body will be an implementation challenge. We
can say that with some confidence because the existing draft already
includes a feature using this indicator:
https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3.3

I haven't seen anyone raising problems with this and there are definitely
implementations in the wild.



On Wed, Sep 5, 2018 at 12:57 PM, Richard Barnes  wrote:

>
>
> On Wed, Sep 5, 2018 at 12:53 PM Salz, Rich  wrote:
>
>>
>>- Because being generous in what you receive is harmful.
>>
>> https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
>> 
>>
>>
>>
>> Sorry, I disagree with King Martin in this case. :)
>>
>>
>>
>> I think mandating a specific requrest body is hard to get right.
>>
>
> Can you point to an implementation framework where this would be
> difficult?  AFAIK, every JSON library out there marshalls {} as "{}", with
> no whitespace, and every JOSE library signs whatever string you give it.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

On Wed, Sep 5, 2018 at 12:53 PM Salz, Rich  wrote:

>
>- Because being generous in what you receive is harmful.
>
> https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
> 
>
>
>
> Sorry, I disagree with King Martin in this case. :)
>
>
>
> I think mandating a specific requrest body is hard to get right.
>

Can you point to an implementation framework where this would be
difficult?  AFAIK, every JSON library out there marshalls {} as "{}", with
no whitespace, and every JOSE library signs whatever string you give it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Salz, Rich]

  *   Because being generous in what you receive is harmful.
https://tools.ietf.org/html/draft-iab-protocol-maintenance-00

Sorry, I disagree with King Martin in this case. :)

I think mandating a specific requrest body is hard to get right.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Salz, Rich]

I like the header, but rather than say the payload MUST be {} (which brings up 
all sorts of whitespace issues at least), maybe we should say the server MUST 
ignore the request body?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

Because being generous in what you receive is harmful.
https://tools.ietf.org/html/draft-iab-protocol-maintenance-00

In case anyone want to try to interop, I updated my lego patch to implement
(1):
https://github.com/bifurcation/lego/pull/1/commits/750383d7ad272a0894d6ff86d4d85d38f965c14f


On Wed, Sep 5, 2018 at 12:44 PM Salz, Rich  wrote:

> I like the header, but rather than say the payload MUST be {} (which
> brings up all sorts of whitespace issues at least), maybe we should say the
> server MUST ignore the request body?
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Daniel McCarney]

#1 sounds OK to me

On Wed, Sep 5, 2018 at 11:33 AM, Richard Barnes  wrote:

> I'm tempted to say that the "" / null ambiguity is an interop problem for
> JOSE, not for us.  But nonetheless, it's a problem.
>
> I'm still uncomfortable with {}, though, because it risks colliding with
> other POST uses.  What would you guys think about one of these explicit
> markers:
>
> 1. A field in the protected header ("urn:ietf:params:acme:get": true) with
> a requirement that the payload be "{}"
> 2. A field in the payload ({"get": true}) a requirement that if that field
> be there, then there are no other fields present
>
> Personally, I find (1) a little more explicit.  It's a little more bloat
> because of the URN cruft, but (1) it doesn't make sense to register a
> generic, unprefixed parameter, and (2) checking for "{}" is easier than
> checking for "no other fields".
>
> --Richard
>
> On Tue, Sep 4, 2018 at 3:17 PM Logan Widick 
> wrote:
>
>> I like using {} for the POST-as-GET payload as well.
>>
>> Sincerely,
>>
>> Logan Widick
>>
>> On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews  wrote:
>>
>>> New day, new thread for a specific issue I'd like to nail down quickly.
>>>
>>> > ISSUE 2: How should we signal that POST-as-GET request is different
>>> > from other POST requests?
>>> >
>>> > The current PR signals this by sending a JWS with an empty
>>> > (zero-octet) payload, instead of a JSON object.  Jacob and Daniel
>>> > suggested that we should instead use the payload being an empty JSON
>>> > object as the signal.  An earlier draft PR used a field in the
>>> > protected header.
>>>
>>> In short, this question is about whether POST-as-GETs should have:
>>>
>>> "payload": ""
>>>
>>> or
>>>
>>> "payload": "{}"
>>>
>>>
>>> When implementing the first one (empty payload), Daniel and I each
>>> separately implemented a different bug that would have also accepted:
>>>
>>> "payload": null
>>>
>>> This may be quirk of Go's handling of byte arrays, but it may turn out
>>> to be a common pattern in JSON libraries. The downside, if a server
>>> implementer landed a bug like that, would be that clients might get away
>>> with generating the invalid "null" form, leading to interoperability
>>> problems.
>>>
>>> There's also potential for client bugs that produce an empty payload
>>> simply due to an uninitialized field, rather than due to a POST-as-GET.
>>> This would produce confusing errors relating to GETs rather than a
>>> clearer "malformed input" error.
>>>
>>> Lastly, many clients already implement the "{}" form as a way to GET an
>>> account, so expanding the use of "{}" minimizes disruption.
>>>
>>> My preference is still for "{}" over "", but I am also willing to be
>>> convinced in the interests of landing this change speedily and keeping
>>> forward momentum.
>>>
>>> ___
>>> 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
>>
>
> ___
> 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

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

I'm tempted to say that the "" / null ambiguity is an interop problem for
JOSE, not for us.  But nonetheless, it's a problem.

I'm still uncomfortable with {}, though, because it risks colliding with
other POST uses.  What would you guys think about one of these explicit
markers:

1. A field in the protected header ("urn:ietf:params:acme:get": true) with
a requirement that the payload be "{}"
2. A field in the payload ({"get": true}) a requirement that if that field
be there, then there are no other fields present

Personally, I find (1) a little more explicit.  It's a little more bloat
because of the URN cruft, but (1) it doesn't make sense to register a
generic, unprefixed parameter, and (2) checking for "{}" is easier than
checking for "no other fields".

--Richard

On Tue, Sep 4, 2018 at 3:17 PM Logan Widick  wrote:

> I like using {} for the POST-as-GET payload as well.
>
> Sincerely,
>
> Logan Widick
>
> On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews  wrote:
>
>> New day, new thread for a specific issue I'd like to nail down quickly.
>>
>> > ISSUE 2: How should we signal that POST-as-GET request is different
>> > from other POST requests?
>> >
>> > The current PR signals this by sending a JWS with an empty
>> > (zero-octet) payload, instead of a JSON object.  Jacob and Daniel
>> > suggested that we should instead use the payload being an empty JSON
>> > object as the signal.  An earlier draft PR used a field in the
>> > protected header.
>>
>> In short, this question is about whether POST-as-GETs should have:
>>
>> "payload": ""
>>
>> or
>>
>> "payload": "{}"
>>
>>
>> When implementing the first one (empty payload), Daniel and I each
>> separately implemented a different bug that would have also accepted:
>>
>> "payload": null
>>
>> This may be quirk of Go's handling of byte arrays, but it may turn out
>> to be a common pattern in JSON libraries. The downside, if a server
>> implementer landed a bug like that, would be that clients might get away
>> with generating the invalid "null" form, leading to interoperability
>> problems.
>>
>> There's also potential for client bugs that produce an empty payload
>> simply due to an uninitialized field, rather than due to a POST-as-GET.
>> This would produce confusing errors relating to GETs rather than a
>> clearer "malformed input" error.
>>
>> Lastly, many clients already implement the "{}" form as a way to GET an
>> account, so expanding the use of "{}" minimizes disruption.
>>
>> My preference is still for "{}" over "", but I am also willing to be
>> convinced in the interests of landing this change speedily and keeping
>> forward momentum.
>>
>> ___
>> 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Logan Widick]

I like using {} for the POST-as-GET payload as well.

Sincerely,

Logan Widick

On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews  wrote:

> New day, new thread for a specific issue I'd like to nail down quickly.
>
> > ISSUE 2: How should we signal that POST-as-GET request is different
> > from other POST requests?
> >
> > The current PR signals this by sending a JWS with an empty
> > (zero-octet) payload, instead of a JSON object.  Jacob and Daniel
> > suggested that we should instead use the payload being an empty JSON
> > object as the signal.  An earlier draft PR used a field in the
> > protected header.
>
> In short, this question is about whether POST-as-GETs should have:
>
> "payload": ""
>
> or
>
> "payload": "{}"
>
>
> When implementing the first one (empty payload), Daniel and I each
> separately implemented a different bug that would have also accepted:
>
> "payload": null
>
> This may be quirk of Go's handling of byte arrays, but it may turn out
> to be a common pattern in JSON libraries. The downside, if a server
> implementer landed a bug like that, would be that clients might get away
> with generating the invalid "null" form, leading to interoperability
> problems.
>
> There's also potential for client bugs that produce an empty payload
> simply due to an uninitialized field, rather than due to a POST-as-GET.
> This would produce confusing errors relating to GETs rather than a
> clearer "malformed input" error.
>
> Lastly, many clients already implement the "{}" form as a way to GET an
> account, so expanding the use of "{}" minimizes disruption.
>
> My preference is still for "{}" over "", but I am also willing to be
> convinced in the interests of landing this change speedily and keeping
> forward momentum.
>
> ___
> 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