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?
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.
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.
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
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.
This email brought to you by the number 2 and the letters J, W, and S :)
--Richard
[1] Note that the default value for this header must be false, or else you
lose the compactness advantage!
[2] You could also do this as a "Content-Encoding" equivalent, "cenc":
"b64". That would give you "base64 agility", as some folks have asked for,
since you could have "b64" and "b64u" values.
[3] You could also do this like CMS, and have the JWS Signing Input in the
latter case be "the concatenation of the Encoded JWS Header, a period ('.')
character, and the Encoded JWS Payload Hash". Where the Encoded JWS
Payload Hash is the base64url-encoded version of the hash you would
otherwise be signing. This seems simpler to code, since you just digest
the body, then if there's a protected header, you digest again. But it
also breaks with existing code.
On Thu, Jun 27, 2013 at 1:11 PM, Jim Schaad <[email protected]> wrote:
> No, my motivation is to allow for a smaller version of the payload string.
> In some cases quoting it will generate a smaller string than doing the
> base64 conversion on the string.
>
>
>
> > -----Original Message-----
> > From: Mike Jones [mailto:[email protected]]
> > Sent: Thursday, June 27, 2013 9:49 AM
> > To: Jim Schaad; 'n-sakimura'
> > Cc: [email protected]; [email protected]
> > Subject: RE: [jose] #26: Allow for signature payload to not be base64
> encoded
> >
> > Jim, you wrote "If I am not transporting the base64url encoded content,
> > because it is not in the "payload" field, then why should I need to
> base64
> > encode it just to validate the signature. This is the alto case."
> >
> > So am I correct then, in thinking that your motivation for #26 is
> actually #25 -
> > Detached content for the ALTO use case? As John and Nat had written,
> this
> > could be handled by the specs as they are today by signing a hash of the
> > detached content and including a compact JWS representing that signature
> as
> > an x-alto-signature header. That doesn't require changing the signature
> > calculation.
> >
> > -- Mike
> >
> > -----Original Message-----
> > From: Jim Schaad [mailto:[email protected]]
> > Sent: Thursday, June 27, 2013 9:41 AM
> > To: 'n-sakimura'
> > Cc: [email protected]; Mike Jones;
> > [email protected]
> > Subject: RE: [jose] #26: Allow for signature payload to not be base64
> encoded
> >
> > Nat,
> >
> > The only thing that can be signed or encrypted is an octet string. (A
> slight over
> > generalization. GOST for example hashes an integer, tree hashes can do
> > strange things but a sufficiently true statement for our purposes.)
> >
> > A that being said - yes case 1 would be something you can do. Case #2
> would
> > not be something that you can do because it is not an octet string.
> >
> > If you are looking at JavaScript, in order to hash something as an octet
> string it
> > can be one of three things. A UInt8Array, an Int8Array and, due to
> > convention, a string where the top byte of all of the code points in the
> string is
> > zero.
> >
> > We currently don't have an efficient way to encode the Uint8Array case,
> > although that might not be true if we are looking at new ECMA
> specifications
> > which apparently are adding more defined types and serialization methods
> for
> > those types.
> >
> > > -----Original Message-----
> > > From: n-sakimura [mailto:[email protected]]
> > > Sent: Wednesday, June 26, 2013 7:55 PM
> > > To: Jim Schaad
> > > Cc: [email protected];
> > > [email protected]; [email protected]
> > > Subject: Re: [jose] #26: Allow for signature payload to not be base64
> > > encoded
> > >
> > > Let me understand the problem.
> > >
> > > Are you suggesting that we should be able to do something like:
> > >
> > > Case 1:
> > >
> > > {"protected":<integrity-protected shared header contents>",
> > > "unprotected":<non-integrity-protected shared header contents>",
> > > "payload":"this is a multi\nline text payload of which a line
> > > can be very very very long and wrapped during transmission. "
> > > "signatures":[
> > > {"header":"<per-signature unprotected header 1 contents>",
> > > "signature":"<signature 1 contents>"},
> > > ...
> > > {"header":"<per-signature unprotected header N contents>",
> > > "signature":"<signature N contents>"}],
> > > }
> > >
> > > or even
> > >
> > > Case 2:
> > >
> > > {"protected":<integrity-protected shared header contents>",
> > > "unprotected":<non-integrity-protected shared header contents>",
> > > "payload":{
> > > "this":"is a json",
> > > "payload":"which is not base64url encoded"
> > > }
> > > "signatures":[
> > > {"header":"<per-signature unprotected header 1 contents>",
> > > "signature":"<signature 1 contents>"},
> > > ...
> > > {"header":"<per-signature unprotected header N contents>",
> > > "signature":"<signature N contents>"}],
> > > }
> > >
> > > Then, I am worried about allowing them because in general we would not
> > > know what would a transmission mechanism and user agents (including
> > > text
> > > editors) would do to them, like Mike mentioned. I do not think we
> > > should assume the property of the transmission mechanism in JOSE level.
> > > Assuming that would cause brittleness in the implementations.
> > >
> > > For detached signature, I do not understand why you would want non-
> > > base64url encoded payload. The application should define how to hash
> > > the octet stream that it wants to calculate signature over it, and we
> > > can just include the base64url encoded hash in the "payload".
> > > Why would you like to do other encoding for the hash?
> >
> > If I am not transporting the base64url encoded content, because it is
> not in
> > the "payload" field, then why should I need to base64 encode it just to
> > validate the signature. This is the alto case.
> >
> > Jim
> >
> > >
> > > --
> > > Nat Sakimura ([email protected])
> > > Nomura Research Institute
> > >
> > > PLEASE READ:
> > > The information contained in this e-mail is confidential and intended
> > > for the named recipient(s) only.
> > > If you are not an intended recipient of this e-mail, you are hereby
> > > notified that any review, dissemination, distribution or duplication
> > > of this message is strictly prohibited. If you have received this
> > > message in error, please notify the sender immediately and delete your
> > copy from your system.
>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
