On 2015-10-29 08:16, Mark Watson wrote:
On Thu, Oct 29, 2015 at 4:07 PM, Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
On 2015-10-29 07:44, Mike Jones wrote:
This may be just my personal opinion, but preserving member creation
order is only one small part of producing canonical JSON, which would be what
would be required for such a scheme to be guaranteed to work. For instance, if
the value 1e3 is part of the JSON input, will JSON.stringify() be guaranteed to
emit it as 1e3, or might it be 1E3 or 100? Unless it's deterministic,
different serializers will produce different results, and therefore different
signatures. Without a canonical JSON being both defined and widely deployed, I
can't recommend doing any work that requires a canonical JSON representation to
deterministically succeed.
Mike,
There is no absolute need for a canonical format, but normalization of
numbers is as you mention not without challenges.
Also strings. Any character in a JSON string can be replaced with the \uxxxx
format, changing the serialization without changing the string.
Mike,
I can't speak for all JSON-parsers in the world but the ES6-variant do the
right thing already (normalize strings) and that's good enough for a standard
that (primarily) would target ES6 (and JSON systems compatible with ES6).
Anders
Unless you have canonical serialization you are going to need to insert / extract the
signature member "manually" (without really parsing) to convert to / from the
object-with-signature and the object-to-be-signed.
...Mark
However, as described in the linked document there is a pretty simple
"workaround" which I believe is fully ES6-compatible.
It certainly isn't ideal building standards on workarounds but pragmatism
apparently ruled when Ecma specified ES6 property order so why couldn't the
same thinking be used for signatures? The workaround could maybe even go away
with a future ES iteration if the Ecma ES committee is notified of the issue.
Anyway, this is not [at all] about dismissing JWS, it is about offering an
alternative which has some pros and cons versus JWS. The in-object scheme
cannot easily deal with multiple signature for example.
Regarding non-ES parsers, I don't see that as a showstopper; JavaScript is
the origin of JSON and now it has changed.
Cheers,
Anders
-- Mike
-----Original Message-----
From: jose [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Anders Rundgren
Sent: Wednesday, October 28, 2015 11:40 PM
To: [email protected] <mailto:[email protected]>
Subject: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures
ES6-compliant in-object JS/JSON signature:
var inObjectSignedData =
{
// Object data expressed as JS properties
"device": "Pump2",
"value": 1e-18,
// Object signature
"signature": {
...Protected headers + Signature value expressed as JS
properties...
}
};
JavaScript's JSON.parse() and JSON.stringify() suffice for
"canonicalization" purposes.
Converting the above to JWS JSON Serialization you would get:
var signedData =
{
// Object data in a coded format
"payload":"<payload contents>",
// Protected headers wrapped in Base64URL
"protected":"<integrity-protected header contents>",
// Signature in a unique format
"signature":"<signature contents>"
}
ES6 was released in June 2015 so this opportunity is actually quite new.
Cheers,
Anders
http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html#rfc.section.3.3
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
