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

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

What I am proposing is that it is an option to "harden" the content, but is
not required.  What is signed and what is transported are the same, but what
is signed may or may not be suitable for the compact encoding.

One would always be able to switch from the compact to the JSON
serialization, however the reverse transformation may not always be
possible.  This would be one more reason why it would not be possible, but
there are many others.

What I originally described would by how I would approach it from a library
basis.  However, there are many things that applications can do that are not
doable by a library and a library would only give some additional options to
what was doable.  This means that while I said that the application would be
required to base64url encode the content, it could do this by passing an
indicator to the library that this was the desired behavior (for example by
calling the SignForCompactEncoding function).

The primary purpose of base64 encoding is not to harden the content to
protect from changes, it is to allow you to do the compact encoding and
transport it in a URL.   If you are worried about things which are going to
muck with the content, they are going to be happy to parse it up, unbase64
encode it, muck with it and write it back out.  This does not prevent a
determined entity from doing the mucking.   If I pass the content as a
string field in a JSON encoded object, then nobody is going to much with it
by default.  They are going to need to know that the need to muck with it
before they start.

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 12:10 PM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: RE: [jose] #26: Allow for signature payload to not be base64
encoded
> 
> 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