> > 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.
Forbidding \uhhhh means you are forbidding 27 control chars (eg U+0007 BELL)
whose only legal JSON representation is in the form \u00hh.
That is probably fine for many apps, but not for a general purpose JSON signing
scheme.
> > I'm not sure what "UTF-8 order" is: sorting on Unicode scalar values
> > would be better.
> Fixed.
How is this JSON object sorted? {"a\"b":1,"a#b":2}
P.S. Your code fails to handle \x escapes in object element names. That is,
scanProperty() should call scanQuotedString(). Also, an empty string "" is a
perfectly valid (if unusual) object element name.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
