On 2013-09-03 03:20, Manger, James H wrote:
>>> 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.
James,
I have like 4 weeks of practical experience with JSON so I'm obviously _not_ an
authority on every aspect of it.
However, I would be _surprised_ (have though happened before...) if what you
write is valid for the majority of parsers out there; at least it would depart
from how many other text-processing-systems usually work.
That is, if you give a JSON serializer the Java literal "hi\u0007" I would
expect the output to actually contain three characters within quotes.
The IMO only reason for special treatments of certain characters like \" is
because parsing would fail otherwise.
BELL should from a parser's point-of-view be no different than a EURO sign
(when featured within a quoted string NB...).
>
>
>
>>> 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}
Here I would like to refer to the following lines in the specification:
"Disclaimer: This document does not represent a standard of any kind.
It might at best be useful as input to a future standardization process"
:-)
>
> 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.
Thanx, I will (eventually) look into this. It is on the "edge" IMO.
If anybody feel tempted doing standardization work on something "JCS-ish", it's
up for grabbers; I don't have the motivation (or funding) for that.
Right now I'm simply very pleased (after an intense week with pretty major
iterations based on constructive input), having an ultra-simple clear-text
signature scheme that is _way_ more suitable for supporting verbose
security-protocols than heavy-footed XML standards.
Cheers
Anders
>
> --
> James Manger
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
