Anders, thanks again for the pointers. Interesting reading. I like your approach a lot. While crawling though the web I stumbled upon this fall asleep draft:
https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 Have you been aware of this one!? Anyway, I still think that JOSE requires a readable JSON serialisation. I am not really familiar with the IETF procedures and seing that no one else reacted on the suggestion so far, I guess that raising such thoughts in the mailing list is not enough. What needs to be done in order to have a discussion on replacing the flatened JSON serialisation by a readbale JSON serialisation? Thanks and BR, Luigi. Am 13.03.15 um 10:01 schrieb Anders Rundgren: > On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >> Seems that there is some uncertainty about this "special" serialisation. >> I would actually vote for replacing the flatened JSON serialisation with >> one, that provides a real benefit. Taken up on a discussion I read >> earlier on the list, wouldn't it be more sensible to have a "readable" >> JSON serialisation (i.e., leaving the signed payload "human readbale")!? >> This would of course require some form of normalisation/canonicalisaton >> as used e.g. in XML Security. Still, this would be something valuable to >> have and a real distinguishing point in comparison to the other >> serialisations. >> >> If people think that this is worth a discussion, then maybe we should >> kick-off an explicit thread on it. > > Human-readable JSON signatures is a reality although not as an IETF > standard. > > Since nobody is interested in bringing in the complexity of XML DSig > normalization, > there seems to be some possible routes ahead. > > Phillip Hallam-Baker have proposed a scheme based on separating the > payload and > the signature where the payload is used "verbatim" reducing > normalization and > canonicalization to exactly ZERO: > http://www.ietf.org/mail-archive/web/acme/current/msg00224.html > > I have FWIW designed and also implemented a scheme which is based on JSON's > intrinsic normalization (white-space removal + character escapes) but > adds the > constraint that a verifier honors the property order of the serialized > object: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html > Since a JSON parser-core typically is less than 500 lines of fairly > simple code > I don't see that upgrading existing parsers with an ordered dictionary > would be > a show-stopper. It surely didn't stop me at least :-) > Runnable Java+JavaScript implementation: https://mobilepki.org/jcs > Partial Python implementation: > https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py > > Minimal .NET implementation: > https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs > > > Cheers, > Anders >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
