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

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

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