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

[Mike Jones <[e-mail]>]

Maybe I'm confused about what you were proposing.  These are the two ways of doing something that I thought you were describing:

1.  Have the signature payload be base64url encoded (the status quo)
2.  Have the signature payload be unencoded in the JSON Serialization if a flag is set in the header

If you're proposing that the default be unencoded for the JSON Serialization, that has the pitfall that a simple syntactic transformation is no longer possible between the Compact Serialization and the JSON Serialization.  The two would have unnecessarily diverged.

If I misunderstood your proposal, maybe you could describe it in closer to normative language - for instance, defining the flag you propose to say that the payload is not base64url encoded and saying what its semantics would be for the JSON Serialization and the Compact Serialization.

BTW, your response didn't address the point that a primary purpose of the base64url encoding is to harden the payload against changes that might otherwise occur during transmission.  Not hardening the payload will almost certainly lead to hard-to-debug interop problems in practice.

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Wednesday, June 26, 2013 11:30 AM
To: [e-mail]; Mike Jones
Cc: [e-mail]
Subject: 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: [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