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

["Manger, James H" <[e-mail]>]

Separate names to hold the payload as a base64url-encoding ("payload") or as a string ("verbatim") is a better approach than a "cenc" header field. At some point we might add a third name ("payload_uri") to identify the content without including it in the JSON.

One hassle we are having is that transmitting the payload in B64, or as a string, or externally, or by reference isn’t merely a serialization choice, but actually affects the bytes that are signed (so it potentially changes the security properties so it requires lots of care). Understandably, but unfortunately, many are reluctant to make changes to tackle this at this point.

A related issue is that the "alg" value is no longer sufficient to indicate the bytes that are signed. This is one reason why a “mode” concept would be helpful (along with a "mode" field, with defaults for compatibility with current drafts).

--
James Manger

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Thursday, 4 July 2013 7:33 AM
To: John Bradley; Richard Barnes
Cc: Jim Schaad; n-sakimura; [e-mail]; Dick Hardt
Subject: 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