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

[n-sakimura <[e-mail]>]

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?

-- 
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.