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

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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Tuesday, June 25, 2013 5:23 PM
> To: draft-ietf-jose-json-web-signature@tools.ietf.org;
> michael.jones@microsoft.com
> Cc: jose@ietf.org
> 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 michael.jones@microsoft.com)
> 
>  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-
>   ietf@augustcellars.com |  signature@tools.ietf.org
>      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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose