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" <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >> jose issue tracker >> Sent: Tuesday, June 25, 2013 5:23 PM >> To: [email protected]; >> [email protected] >> Cc: [email protected] >> 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 [email protected]): >> >> 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- >> [email protected] | [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
