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

[Mike Jones <[e-mail]>]

In the spirit of compromise, and to help further the discussion on this topic, I thought I'd suggest a possible syntax for the JWS JSON Serialization for representing an unencoded payload as a JSON string.  One way of allowing either encoded or unencoded payloads would be to use different JSON member names for them.  For instance, one could allow either of these names, but not both, in any particular JWS using the JSON Serialization:

    "payload" - Contains base64url encoded JWS Payload representation
    "verbatim" - Contains unencoded JWS Payload representation

So then, for instance, these three alternative representations would all represent the same JWS Payload:
    "payload": "SGVsbG8gd29ybGQ"
    "verbatim": "Hello world"
    "verbatim": "Hello\u0020world"

As for the signature computation, in the "payload", case there would be no change from the present.  In the "verbatim" case, I assume that the logical thing to do would be to use the octets of the UTF8 representation of the payload string in the signing input - in this example, 72 101 108 108 111 32 119 111 114 108 100.

This approach would avoid the problem I had discussed earlier of there being a default that is different than the Compact Serialization.  There would be no default.  Those encoding the content would choose either the "payload" or "verbatim" member name.

This does not avoid the problem of there being two different ways to do the same thing in the standard, with the interoperability problems that can result.

I am still not advocating that we support two ways of representing payloads.  But if the working group does decide that it's important to do so, I think that this would be a credible approach for doing so.  I think it would accomplish what Jim is after here.

Thoughts?

                                                            -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Dick Hardt
Sent: Friday, June 28, 2013 4:04 PM
To: Richard Barnes
Cc: Jim Schaad; n-sakimura; Mike Jones; [e-mail]; [e-mail]
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded

Hi Richard, that helps.

Our you looking at a way of effectively signing a JSON payload? A complete, real world example would help alot.

On Fri, Jun 28, 2013 at 3:57 PM, Richard Barnes <[e-mail]<mailto:[e-mail]>> wrote:
Hey Dick,

I guess I should have been clearer that I was only talking about the JSON serialization.  My proposed change would have no impact on the compact serialization.  Hopefully that answers your questions about separators, etc.; they payload would just be a normal JSON string.

--Richard

On Thu, Jun 27, 2013 at 7:56 PM, Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:


On Thu, Jun 27, 2013 at 3:24 PM, Richard Barnes <[e-mail]<mailto:[e-mail]>> wrote:
I think there are two separable issues here, both of which Mike and I probably have divergent opinions on :)
1. Syntax: Should it be possible for the "payload" field JWS to be a JSON string (instead of base64) when the payload is simply a UTF-8 string?

One of the goals of the token was that it not require encoding for it to be transported in a request. IE that it be safe and SIMPLE to include in an HTTP header or in a URL

2. Crypto: Must the JWS Signing Input be base64url encoded.

The current answers to these questions are:
1. It is not possible.  Payload is always base64url encoded.
2. It is always base64url encoded.

The answers should be:
1. The payload should not be base64url encoded unless it cannot be represented as a JSON string.

How does an implementation determine which parts are separated? Are '.' escaped? Does the implementation need to parse the JSON to determine a valid separator? How does it know the end of the JSON? That sounds really hard to implement, or I am misunderstanding what you are proposing.


2. The JWS Signing Input should not be base64url encoded unless there is a JWS Protected Header

Neither of these are complicated changes:
1. Add a "b64" header parameter that indicates that the payload is base64url-encoded binary, as opposed to a UTF-8 string.  Specify that this parameter is on by default in compact-formatted JWS objects.

And how is the header separated from the payload?

2. Modify the signing/verification instructions to switch based on the presence of a JWS Protected Header: "If the JWS Protected Header is absent or empty, then the JWS Signing Input is simply the JWS Payload (not encoded).  If the JWS Protected Header has a non-empty value, then the the JWS Signing Input is the concatenation of the Encoded JWS Header, a period ('.') character, and the Encoded JWS Payload"

There are two reasons for these, both of which are important to make sure that this spec is applicable to a broad variety of use cases:
1. Compactness.  As Jim notes, quoted strings are shorter than base64url-encoded strings

The tokens are already compact enough.

2. Crypto-compatibility: Avoiding base64-encoding means that there's nothing JWS-specific about the signature value.  So for example, you could translate a JWS with no protected attributes to a CMS SignedData object with no protected attributes.

Not a useful feature from my point of view.

-- Dick