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: [email protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Thursday, 4 July 2013 7:33 AM
To: John Bradley; Richard Barnes
Cc: Jim Schaad; n-sakimura; [email protected]; 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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
