Re: JWS Clear Text JSON Signature Option (JWS/CT)

On 2020-11-26 12:46, Simon Greatrix wrote:
Hi Simon,

Thank you for your input!

IMO, this is an issue that may better be discussed on the IETF JSON mailing list since it is more related to canonicalization than signatures.  Note that some opinionated persons on this list claim that canonicalization MUST also include sub-types in quotes, otherwise it is not canonicalization.  Pure fun all the day :-)

The current canonicalization solution is indeed "imperfect" but can still cope with any data, including arbitrary big numbers. The only JSON-related IETF specification I'm aware of that goes outside of I-JSON, is the JSON RFC itself.

Although it is true that Gibson's algorithm with your fix would be "perfect", I'd rather wait for the ECMAScript TC or the IETF to take such a step first. However, the Gibson scheme is (and will most likely remain) incompatible with a plain-vanilla JSON.parse("jsonstring") which makes this a difficult project with very limited gain.  Native support of CBOR is probably higher on the wish-list.

 From a practical point of view the potential "mishandling" of sub-types in strings (like ISO DateTime) mentioned in RFC 8785 is the (IMO...) only thing that actually sometimes require a bit of additional work.

Regards,
Anders


> Thank you for raising the awareness of this draft <https://www.ietf.org/archive/id/draft-jordan-jws-ct-00.html>.
>
> I propose that an optional JWS header parameter be introduced to allow the specification of alternative canonicalization methods for situations where a document may not conform to the limitations of I-JSON.
>
> Of the alternative canonicalization efforts listed in RFC8785, they all have issues:
>
>   * https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 <https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00>
>       o Does not specify any form of canonicalization for keys and strings, so cannot be implemented
>   * http://wiki.laptop.org/go/Canonical_JSON <http://wiki.laptop.org/go/Canonical_JSON>
>       o Does not allow floating point numbers, so is more restrictive than I-JSON.
>   * https://gibson042.github.io/canonicaljson-spec/ <https://gibson042.github.io/canonicaljson-spec/>
>       o Supports all valid JSON, but has a security vulnerability with large integers
>
> The gibson042 security vulnerability is that integers are forbidden to use exponents, so 1E+3 must be written as 1000, 1E+6 must be written as 1000000 and 1E+1000000000 requires a gigabyte of storage. This allows a bad actor to perform a denial of service attack by sending small messages that then require very large resources to process. This vulnerability can be resolved by using the non-integer rules for integers, or allowing the use of exponents in integers when the number of trailing zeros exceeds some limit. A maximum of 18 trailing zeros would allow all possible uint64 values to represented without using exponents or decimal points, but prevent the use of large exponents as a denial of service. Unfortunately the gibson042 proposal appears to be orphaned or abandoned so this is unlikely to get addresses at source.
>
> I believe that being able to produce a canonical form for **all** JSON is a worthwhile goal, and the modified gibson042 I’ve just described does exactly that.
>
> To that end I propose:
>
>  1. An optional header parameter be included to allow a non RFC-8785 canonicalization method to be specified
>  2. RFC-8785 canonicalization would be the default method
>  3. The gibson042 proposal, suitably modified to address the security problem, be recognised as a standard
>  4. This method for canonicalization of all JSON documents be listed as an alternative method.
>
> Kind Regards,
>
> Dr Simon Greatrix
>
> *From: *Anders Rundgren <anders.rundgren.net@gmail.com>
> *Date: *Friday, 20 November 2020 at 13:01
> *To: *W3C Credentials Community Group <public-credentials@w3.org>
> *Subject: *JWS Clear Text JSON Signature Option (JWS/CT)
>
> This Internet-Draft may be of interest for people working with signed JSON data:
> https://www.ietf.org/archive/id/draft-jordan-jws-ct-00.html <https://www.ietf.org/archive/id/draft-jordan-jws-ct-00.html>
>
> Abstract:
>    This document describes a method for extending the scope of the JSON
>    Web Signature (JWS) standard, called JWS/CT.  By combining the
>    detached mode of JWS with the JSON Canonicalization Scheme (JCS),
>    JWS/CT enables JSON objects to remain in the JSON format after being
>    signed (aka "Clear Text" signing).
>
> On-line service for testing/evaluation: https://mobilepki.org/jws-ct <https://mobilepki.org/jws-ct>
>
>
> This email from SETL Limited (including any attachments) is confidential and may be privileged. This email is for use by the intended recipient only and no other person. If you receive this email in error, please notify the sender and delete it. You should not rely on, copy or disclose all or any part of this email. SETL Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or all or any part of its content. SETL Limited is Registered in England and Wales No. 11860439. Registered address: 1 Love Lane, London, England, EC2V 7JN. "SETL" is a registered trade mark of SETL Limited, No. 015010788. Please consider the environment before printing this e-mail