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

[John Bradley <[e-mail]>]

At the moment the signature is calculated over the base64url encoded representation of the payload and not the binary string.  

Having two different ways to calculate the signature seems like the wrong thing.  

If we were talking about always calculating the signature over the binary string and then dealing with encoding as a later step I would understand your point better but the flag is changing the processing as well as the representation.

However that would render the compact and JSON forms incompatible without recalculating the signature.

What are the issues with including a 8-bit string in a JSON sting?

What you are proposing seems like a large fundamental change, that would require a matching change in compact, that complicates that format.

Perhaps I am not understanding your proposal.

John B.

On 2013-06-26, at 2:29 PM, "Jim Schaad" <[e-mail]> wrote:

> Having multiple ways to do something can frequently buy you a great deal of benefit.  However, in this case it is my library that is doing this and not the standard.
> 
> The client gives the library an 8-bit string.  The library signs that string.  The library puts that string into the payload field.
> 
> The client needs to make the 8-bit string URL safe if it wants to use compact encoding.
> 
> Where is there two ways of doing something?
> 
> Jim
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> jose issue tracker
>> Sent: Tuesday, June 25, 2013 5:23 PM
>> To: [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded
>> 
>> #26: Allow for signature payload to not be base64 encoded
>> 
>> 
>> Comment (by [e-mail])
>> 
>> Having multiple ways to do something is one of the classic pitfalls to  avoid in
>> standards.  They tend to generate interop problems because  developers will
>> often only build the way that they think they need, never
>> getting around to the others.   I don t think the potential benefits of
>> having multiple ways to encode the payload outweigh this cost.
>> 
>> Next, this feature would only work with the JSON serialization; it would  not
>> work for the Compact Serialization because the payload must be URL  safe.
>> The base64url encoding accomplishes that, and so is a necessary  part of the
>> encoding.  Having the two serializations diverge in this  manner seems
>> suboptimal.
>> 
>> Third, I am concerned that the payload will sometimes change during
>> transmission if not encoded in some manner.  Tabs can change to spaces.
>> LFs can change to CRLFs.  HTML is notorious for adding a blank at the end  of
>> each line.  Two spaces can change to a space and a non-breaking space.
>> Etc.  Not encoding the payload would open us up to all of these potential
>> modification-during-transmission problems   all of which would render the
>> JWS useless by breaking the signature.
>> 
>> Finally, this feature seems to be motivated by detached signatures, which  per
>> my comment on Ticket #25, can be accomplished at the application layer
>> without adding general-purpose support for detached signatures.  Thus, I  don
>> t think this related feature is needed either.
>> 
>> For all these reasons, I believe that this issue should be closed as   won t fix .
>> 
>> --
>> -------------------------+----------------------------------------------
>> -------------------------+---
>> Reporter:               |       Owner:  draft-ietf-jose-json-web-
>>  [e-mail] |  [e-mail]
>>     Type:  defect       |      Status:  new
>> Priority:  major        |   Milestone:
>> Component:  json-web-    |     Version:
>>  signature              |  Resolution:
>> Severity:  -            |
>> Keywords:               |
>> -------------------------+----------------------------------------------
>> -------------------------+---
>> 
>> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/26#comment:1>
>> jose <http://tools.ietf.org/jose/>
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose