On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
Anders,
Hi Luigi,
thanks again for the pointers. Interesting reading. I like your approach
a lot.
Thanx!
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!?
Yes, I think so. As you can see "there are many roads to Rome" :-)
One school says: "You must canonicalize data in a similar way as for XML",
while another school claim that "Canonicalization is lunacy!".
Full canonicalization like in the I-D above forces you to use a stand-alone
canonicalizer which is like building a parallel single-purpose JSON parser.
Using text "as is" makes canonicalization a zero issue but I felt that it would
be cooler using a standard (or moderately updated) JSON parser for creating
and validating signatures. This design also enables security properties like
keys to be handled exactly as any other properties.
When I found (on stackoverflow) that many developers also feel that parsers that
read properties A, B, C but outputs them as A, C, B as inferior, the decision to
maintain strict property input/creation order became obvious.
I'm currently not considering an IETF process, it seems like a better idea
establishing
this scheme through open source and actual usage :-)
JCS was designed for supporting complex signature systems like:
https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserSignedAuthorization
Regards,
Anders
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
