Subject: [jose] JWS Signing Input Options specification enabling non-base64-encoded payloads when safe to do so

From: Mike Jones <[email-masked]>
Date: Thu, 28 May 2015 00:06:49 +0000

There's been interest being able to not base64url-encode the JWS Payload under some circumstances by a number of people.  I've occasionally thought about ways to accomplish this, and prompted again by discussions with Phillip Hallam-Baker, Martin Thomson, Jim Schaad, and others at IETF 92 in Dallas, recollections of conversations with Matt Miller and Richard Barnes on the topic, and with Anders Rundgren on the JOSE mailing list, I decided to write down a concrete proposal while there's still a JOSE working group to possibly consider taking it forward.  The abstract of the spec is:

JSON Web Signature (JWS) represents the payload of a JWS as a base64url encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url-encode the payload.

Also, JWS includes a representation of the JWS Protected Header and a period ('.') character in the JWS Signature computation. While this cryptographically binds the protected Header Parameters to the integrity protected payload, some of have described use cases in which this binding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not include a representation of the JWS Protected Header and a period ('.') character in the JWS Signing Input.

These options are intended to broaden the set of use cases for which the use of JWS is a good fit.

This specification is available at:

*         https://tools.ietf.org/html/draft-jones-jose-jws-signing-input-options-00

An HTML formatted version is also available at:

*         http://self-issued.info/docs/draft-jones-jose-jws-signing-input-options-00.html

                                                                -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1398 and as @selfissued.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 May 2015 06:14:43 +0200

On 2015-05-28 02:06, Mike Jones wrote:
> There’s been interest being able to not base64url-encode the
 > JWS Payload under some circumstances by a number of people.
 > I’ve occasionally thought about ways to accomplish this, and
 > prompted again by discussions with Phillip Hallam-Baker, Martin Thomson,
 > Jim Schaad, and others at IETF 92 in Dallas, recollections of conversations
 > with Matt Miller and Richard Barnes on the topic, and with Anders Rundgren
 > on the JOSE mailing list, I decided to write down a concrete proposal while
 > there’s still a JOSE working group to possibly consider taking it forward.

Hi Mike,
It is good to see this going forward!

The current proposals seem to either depend on an external signature parser/generator
or as in my proposal [1], a slightly enhanced JSON serializer/deserializer.

I never bothered about saving bytes; JCS is really only about adding an optional
"Signature" attribute to an existing JSON object which is kind of nice for
processing and documentation.  Although JCS's "predictable serialization" is not
a part of JSON, it is anyway requested by many JSON practitioners.

A guess the problem for JOSE is probably not creating a standard, but getting it
generally adopted since the proposals appear to target quite different use-cases.

Cheers,
Anders

1] https://cyberphone.github.io/openkeystore/resources/docs/jcs.html

> The abstract of the spec is:
>
> ·https://tools.ietf.org/html/draft-jones-jose-jws-signing-input-options-00
>
> ·http://self-issued.info/docs/draft-jones-jose-jws-signing-input-options-00.html
>
>                                                                  -- Mike
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 May 2015 15:46:01 -0400

I very much want this to happen and I think it is best that this happen
here rather than elsewhere as I would like us to have exactly one way to
make use of JOSE signatures in HTTP binding of JSON Web Services.

ACME is definitely going to require something of this sort. The issue is
not the inefficiency of BASE64 encoding itself but the effect of repeated
encoding on nested structures and the loss of readability that BASE64
results in. Someone trying to debug a protocol wants to be able to look at
the examples in the spec and the data they see on the wire and see the
differences. Base64 encoding takes that away.

In the medium term I would like there to be a consistent approach to a HTTP
binding across JSON Web Services because that makes it a lot easier to move
from the HTTP binding to a JSON based binding at some point in the future.

Divergence in protocol styles is usually bad. This helps reduce divergence.
Lets do it.

On Wed, May 27, 2015 at 8:06 PM, Mike Jones <[email-masked]>
wrote:

>  There’s been interest being able to not base64url-encode the JWS Payload
> under some circumstances by a number of people.  I’ve occasionally thought
> about ways to accomplish this, and prompted again by discussions with
> Phillip Hallam-Baker, Martin Thomson, Jim Schaad, and others at IETF 92 in
> Dallas, recollections of conversations with Matt Miller and Richard Barnes
> on the topic, and with Anders Rundgren on the JOSE mailing list, I decided
> to write down a concrete proposal while there’s still a JOSE working group
> to possibly consider taking it forward.  The abstract of the spec is:
>
>
>
> JSON Web Signature (JWS) represents the payload of a JWS as a base64url
> encoded value and uses this value in the JWS Signature computation. While
> this enables arbitrary payloads to be integrity protected, some have
> described use cases in which the base64url encoding is unnecessary and/or
> an impediment to adoption, especially when the payload is large and/or
> detached. This specification defines a means of accommodating these use
> cases by defining an option to change the JWS Signing Input computation to
> not base64url-encode the payload.
>
>
>
> Also, JWS includes a representation of the JWS Protected Header and a
> period ('.') character in the JWS Signature computation. While this
> cryptographically binds the protected Header Parameters to the integrity
> protected payload, some of have described use cases in which this binding
> is unnecessary and/or an impediment to adoption, especially when the
> payload is large and/or detached. This specification defines a means of
> accommodating these use cases by defining an option to change the JWS
> Signing Input computation to not include a representation of the JWS
> Protected Header and a period ('.') character in the JWS Signing Input.
>
>
>
> ·
> https://tools.ietf.org/html/draft-jones-jose-jws-signing-input-options-00
>
>
>
> ·
> http://self-issued.info/docs/draft-jones-jose-jws-signing-input-options-00.html
>
>
>
>                                                                 -- Mike
>
>
>