On 2013-09-02 02:54, Manger, James H wrote: >> ---------- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Anders Rundgren >> Sent: Sunday, 1 September 2013 7:05 PM >> >> New name and updated documentation. >> >> https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON- >> Clear-Text-Signature-Scheme.pdf >> >> Enjoy! > > Anders, > > This is quite an attractive approach — as long as canonicalization works. > A canonical JSON form is viable, though many are reluctant to consider > it due to historical challenges with canonical XML (and DER).
James, Thanx for your input, I _really_ appreciate although I'm not trying to create a standard, only a useful system. Canonicalization is a difficult topic. Since the actual target for JCS are security protocols to be written, rather than legacy applications, I have taken the liberty doing a few shortcuts. > > > The canonical form described in JCS is not precise enough. You are absolutely right. I have updated the spec and code accordingly. > It doesn't discuss escapes in strings (eg "/" vs "\/" vs"\u002f" vs > "\u002F"). Now it does :-) You probably disagree on the result but since JSON parsers are trivial (I know, I just wrote one), the few that may want to support clear-text signatures should be able to perform the needed updates. Compared to the crypto it should be piece of cake. In my mind the JSON clear-text concept gets severely obstructed by the \/ escape. It also creates an artificial gap between the "on-the-wire" and "in-the-doc" worlds. So I simply abolished it! Dealing with \uhhhh on-the-wire is only interesting for "hand-written" JSON and that's completely out-of-scope for JCS. > I'm not sure what "UTF-8 order" is: sorting on Unicode scalar values would > be better. Fixed. > Sorting in descending order (Z before A) is a strange (poor) choice. Fixed. > JCS doesn't define a canonical form for numbers, instead a receiver must > keep the original form. That effectively means you cannot use any "normal" > parser (that returns an int or double when parsing a number). I would put it like this: As an _engineer_ I wouldn't consider using methods that already have been proven to be "brittle". > JSON.stringify [ECMAScript v5.1; > http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.3] > already precisely defines 1 form for any number or string. Add sorting object > elements (and using > lower-case for \uxxxx escapes) and you have great basis for a > highly-interoperable JSON c14n spec. > [see a discussion on the IETF JSON WG list: > http://www.ietf.org/mail-archive/web/json/current/msg00134.html] This is the path for standardization. I'm not going there. Because If I did, I would probably end-up with dangerous stuff like the following extract from draft-ietf-jose-json-web-key-14: The following is a non-normative example of a JWK with a RSA signing key represented both as a bare public key and as an X.509 certificate using the "x5c" parameter: {"kty":"RSA", "use":"sig", "kid":"1b94c", "n":"vrjOfz9CcjBPD5eunqsIo1vQ", "e":"AQAB", "x5c": ["MIIDQjCCAiqgAwIBAgIvACWpkA6SdS4xSvdXK3IVfOWA=="] } How are applications supposed to deal with this? Non-normatively I suppose :-) You use the key that sort of "feels" best? IMHO, this smells "committee" and "edge-cases" a long way... Cheers Anders https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf > > > -- > James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
