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

["Jim Schaad" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, June 26, 2013 7:55 PM
> To: Jim Schaad
> Cc: [e-mail];
> [e-mail]; [e-mail]
> 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 ([e-mail])
> 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.