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

[Richard Barnes <[e-mail]>]

Glad that helped.  Detailed examples below.

Couple of high-level points to help the examples make sense:
1. Define a "cenc" header parameter, for "Content ENCoding", with one
value, "b64u".  When present in the JSON serialization, the "payload" field
is base64url encoded; when it is absent, the "payload" field represents the
payload directly (as a UTF-8 string).
2. For the compact serialization, "cenc" is always "b64u".
3. When protected a header are present (always for the compact
serialization), the JWS Signing Input is base64(protected).base64(payload),
as it is in -11.  When no protected header is present, the JWS Signing
Input is simply the octets of the payload.

With that in mind, let's look at a few test cases.  We'll use the following
inputs:

Header: {"alg":"HS256","kid":"2"}
== 7b22616c67223a224853323536222c226b6964223a2232227d (hex UTF-8)
== eyJhbGciOiJIUzI1NiIsImtpZCI6IjIifQ (base64 UTF-8)

Key (kid=2): 0x0001020304050607 (8 octets)

Payload: "café"
== 636166c3a9 (hex UTF-8)
== Y2Fmw6k (hex UTF-8)

With those inputs, let's consider 4 cases that show the possibilities
discussed above.

### CASE 1: Compact / protected / b64u

eyJhbGciOiJIUzI1NiIsImtpZCI6IjIifQ
.Y2Fmw6k
.QUoMVpjxLXjH1ZAX9tw4QEPnL6G_Hvd4EjD-JsHilyk

No change here.  The compact case just represents the special case where
the payload is base64-encoded and all the headers are protected.  Thus, we
use the base64.base64 form for the JSON Signing Input.
JWS Signing Input: eyJhbGciOiJIUzI1NiIsImtpZCI6IjIifQ.Y2Fmw6k (as a UTF-8
string)
== 65794a68624763694f694a49557a49314e694973496d74705a434936496a496966512e5932466d77366b
(hex)

### CASE 2: JSON / protected / b64u

{
  "unprotected":{"cenc":"b64u"},
  "protected":"eyJhbGciOiJIUzI1NiIsImtpZCI6IjIifQ",
  "payload":"Y2Fmw6k",
  "signature":"QUoMVpjxLXjH1ZAX9tw4QEPnL6G_Hvd4EjD-JsHilyk"
}

This is just the JSON equivalent to Case 1.

### CASE 3: JSON / unprotected / b64u

{
  "unprotected":{"alg":"HS256","kid":"2","cenc":"b64u"},
  "payload":"Y2Fmw6k",
  "signature":"X-GwEVfz9WEi0UhrmK1muKXecqxMipngSL_ZenXw5Lo"
}

Here we've removed the integrity protection from the headers (because who
needs it? ;) ).  So the signature is different, because JWS Signing Input
here is just the payload.
JWS Signing Input: café (as a UTF-8 string)
== 636166c3a9 (hex)

### CASE 4: JSON / unprotected / plain

{
  "unprotected":{"alg":"HS256","kid":"2"},
  "payload":"café",
  "signature":"X-GwEVfz9WEi0UhrmK1muKXecqxMipngSL_ZenXw5Lo"
}

This object is equivalent to Case 3, but with the payload expressed
directly as a JSON string instead of base64-encoded.  And, if you ask me,
the prettiest and most human-readable of the whole menagerie here :)

I've written a script to generate these test cases, in case you want to
play with this some more:
<http://test.polycrypt.net/temp/hello-jose.html>

Hope this helps,
--Richard


On Fri, Jun 28, 2013 at 7:04 PM, Dick Hardt <[e-mail]> wrote:

> 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
>>>
>>
>>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>