The condition you've identified (x == JSON'.parse(JSON.stringify(x))) is necessary, but not sufficient. In the case we're talking about, you also need x == bad_stuff(x). x is being used as input to signature verification, so its bytes cannot change.
It's worth noting that we mandate comparison of strings as unicode code points. So it would not be a huge burden on implementations to have them render x in UTF-8 before putting it into the signature algorithm. That should be stable for all the varieties of bad_stuff() we're talking about, since the only ambiguity is in how the code points are encoded. (That is, no sane JSON library is going to change the actual value of a string, just how it's encoded.) --Richard On Tue, Jun 11, 2013 at 11:56 AM, Carsten Bormann <[email protected]> wrote: > I thought the question was: > > If x is a JSON-text (the content of the protected field), to transport > that unharmed through bad_stuff(), do I need to > > x' = base64url_decode(bad_stuff(base64url_encode(x))) > > or is it enough to carry it around in a JSON string: > > x' = JSON'.parse(bad_stuff(JSON.stringify(x))) > (where JSON and JSON' are the two JSON implementations.) > > A prerequisite for that is that > > x == JSON'.parse(JSON.stringify(x)) > > which I very much hope is true for all actual Unicode strings x. > (If you have unpaired surrogates or other ill-formed UTF-8 in x, all bets > are off.) > > Then the next question is how bad bad_stuff() is, but CRLF or TAB mangling > is demonstrably not a problem, because they cannot occur in a JSON string > representation (only as ignored whitespace around it). > > Grüße, Carsten > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
