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

I'm generally supportive of this idea, and use JCS in a number of areas,
which I will link here for those interested:

Sidetree uses JCS to canonicalize JSON in order to establish stable content
addressable identifiers.

https://github.com/decentralized-identity/sidetree

JcsEd25519Signature2020 is a linked data signature suite that uses JCS
instead of URDNA2015 to canonicalize JSON-LD.

https://w3c-ccg.github.io/ld-cryptosuite-registry/#jcs-ed25519-signature-2020

It's worth noting that linked data signatures already use JCS for `@json`
in JSON-LD, for example lds-jws2020 uses detached JWS and URDNA2015
together:

https://github.com/w3c-ccg/lds-jws2020

Our implementation of did:key exposes some helper methods for created
detached and non detached JWS that use JCS:

https://github.com/transmute-industries/did-key.js/blob/master/packages/did-key-common/src/Jws/index.ts#L29

Pretty much anywhere a json (string) exists, we try to produce them using
JCS instead of JSON.stringify (in javascript).

base64url encoding helps with portability but harms readability and can
provide a false sense of security to those who do not understand the
differences between encoding and encryption.

I think detached JWS and JCS can provide a much better experience in
certain scenarios when compared to vanilla JOSE.

OS




On Thu, Nov 26, 2020 at 11:50 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> 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
>       - 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>
> <anders.rundgren.net@gmail.com>
> *Date: *Friday, 20 November 2020 at 13:01
> *To: *W3C Credentials Community Group <public-credentials@w3.org>
> <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
>
> 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
>
>
> 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
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>