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

[Dick Hardt <[e-mail]>]

On Thu, Jun 27, 2013 at 3:24 PM, Richard Barnes <[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