W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

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

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 4 Dec 2020 08:30:08 +0100
To: public-credentials@w3.org
Message-ID: <158727a1-fd2c-ed7e-4d63-e7e8d6aea526@gmail.com>
Being one of the designers, I would like to share what I consider as "reasonable" requirements for successful usage of JWS/CT.

If we begin with JWS, it is a pretty complex specification. It also supports unusual things like a "none" algorithm which means that if an attacker swapped the original algorithm with "none" the signature would not even be looked at!

In short, JWS requires developers to specify a whole bunch of policies (which presumably are documented in the system design).  How you actually do that depends on the JWS implementation and typically requires a bit of application code as well.

Using JWS/CT requires additional policies but they are (IMO) not overly complex.

   {
     "someData": "...",
     "signature": "ey...."
   }

If a consuming application does not find a "signature" property holding a JSON string argument it should fail in a similar way to what it should do for any other input data errors.

Regarding the underlying canonicalization scheme (RFC 8785), a non-compliant implementation or usage would introduce interoperability issues since signatures most likely would not validate.  However, invalid signatures should not (in any properly designed system), create security breaches.


That is, JWS/CT does indeed not protect against ignorant developers or system designers.

Thanx,
Anders
https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/jose/jws/package-summary.html
Received on Friday, 4 December 2020 07:30:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 4 December 2020 07:30:25 UTC