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

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
     *   Does not specify any form of canonicalization for keys and strings, so cannot be implemented
  *   http://wiki.laptop.org/go/Canonical_JSON
     *   Does not allow floating point numbers, so is more restrictive than I-JSON.
  *   https://gibson042.github.io/canonicaljson-spec/
     *   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