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

[Dick Hardt <[e-mail]>]

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]> 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]> wrote:
>
>>
>>
>>
>> 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
>>
>
>