> -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Anders Rundgren > Sent: Saturday, December 20, 2014 11:16 AM > To: Richard Barnes > Cc: [email protected] > Subject: Re: [jose] JOSE.Next - Clear-Text Signatures? > > On 2014-12-20 18:33, Richard Barnes wrote: > > Clear-text signing requires c14n or some other representation-fixing. > > If you have proposals for at least one of those, this may be viable. > > As mentioned in the "prospectus" there are multiple ways ahead. Some kind > of canonicalization scheme is undoubtedly one of them. > > > Relying on implementation quirks is not OK. > > My specific proposal does not build on implementation quirks but on an > explicitly required serialization method which doesn't "scramble" data. > This may or may not be supported by the target JSON parser. Since JSON > parsers usually are pretty simple I don't see this as a insurmountable obstacle: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Int > eroperability
Based on a quick scan of this, all we need to do is to define a new parser, a new data format (need to keep both the original text and the value for some types) and a new serializer and we are home free. I don't think that is a viable proposal. Jim > > Targeting the lowest common denominator is the governing standards > strategy. > IMO, this [often] thwarts innovation and creates lousy systems so I don't care > :-) > > Cheers, > Anders > > > > > > --Richard > > > > On Sat, Dec 20, 2014 at 12:52 AM, Anders Rundgren > <[email protected] > <mailto:[email protected]>> wrote: > > > > Hi List, > > In theory JOSE is done since we have key containers, as well as signature > and encryption constructs. > > > > In reality it is not because the topic I raised a long time ago namely the > ability to sign clear-text > > JSON data in a similar fashion like in XML DSig simply isn't going away: No, > it is not only yours > > truly who is into JSON clear-text signing although it seems that everybody > is dealing with this > > issue in quite different ways. This may actually only be good since then > there are some > > real-world (tested) schemes to select from. AFAICT they all have (even > including my own take > > on the subject...), clearly identifiable pros and cons. > > > > The rationale is simple: Documentation, Validation, Development and > Debugging of > > complex JSON messages becomes easier if the content is provided in > clear. > > > > There could be justification for IETF taking on such a work-item. > > > > Anders > > > > _________________________________________________ > > jose mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/__listinfo/jose > > <https://www.ietf.org/mailman/listinfo/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
