Re: [jose] #26: Allow for signature payload to not be base64 encoded

As I'd written earlier, *if* the working group decides to also support a payload representation that is not base64url encoded (and I think that's a big *if*), I believe that it should apply only to the JSON Serialization and use an alternative member name, so that the current JSON Serialization objects are unchanged.
For instance, these three alternative representations could all represent the same JWS Payload:
    "payload": "SGVsbG8gd29ybGQ"
    "verbatim": "Hello world"
    "verbatim": "Hello\u0020world"

As I see it, we shouldn't change the meaning of "payload" at this point, without as Karen put it, "a strong rationale and a ground swell of working group support".

                                                                -- Mike

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Wednesday, July 03, 2013 2:25 PM
To: Richard Barnes
Cc: Dick Hardt; Jim Schaad; n-sakimura; Mike Jones; jose@ietf.org; draft-ietf-jose-json-web-signature@tools.ietf.org
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded

For a JWT the content is a JSON object.  For JOSE that restriction doesn't apply, and the content could be any binary data.  That is one of the reasons people want to put additional JSON in the envelope as they may not be able to that easily as part of the body.

Just for the record I am one of the people on the side of integrity protecting headers unless there is a strong reason not to as is the case with multiple recipients and counter mode encryption.

John B.

On 2013-07-03, at 5:15 PM, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:

On Wed, Jul 3, 2013 at 1:55 PM, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
On Wed, Jul 3, 2013 at 9:04 AM, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
On Tue, Jul 2, 2013 at 8:14 PM, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
Hi Richard, thanks for the example, some comments and questions:

To clarify, in the JSON (non-compact) version, the payload is restricted to being a string? ie. it cannot be a JSON object? If so, that seems really limiting.

The payload can be anything that can be expressed as a JSON string.  The payload needs to be serialized, not as a JSON entity (object, array, number), because it's going to be input to a signature verification operation (so it needs to be canonical).  Every JSON string has a unique representation in UTF-8, so we can use that for anything that can be put into a string.

So it is just a string that has had control characters escaped (",\,/,backspace, formfeed, newline, carriage return, horizontal tab)

This is in sharp contrast to the compact form that takes a JSON object.

I have a hard time understanding how this even fits into the WG Charter as your proposal is not transporting JSON. (yes, a JSON string is part of JSON, but it does not have the value proposition that a JSON object has)

Am I missing something?

-- Dick

Yeah, I think you might be a little confused.  Right now, the payload can be any octets -- JSON, UTF-8, EBCDIC, JPEG, QuickTime, whatever. That's true for both the JSON and compact serializations. And that's why in general, the payload has to be base64-encoded to be able to carry it in JSON.

This proposal is just saying that when you have content that can be represented as UTF-8 (e.g., JSON or HTML), you don't have to base64 encode it, you can just stick it in a JSON string.

--Richard

_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose