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

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, June 27, 2013 9:41 AM
To: 'n-sakimura'
Cc: [e-mail]; Mike Jones; [e-mail]
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:[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.