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

Mike Jones <Michael.Jones@microsoft.com> Thu, 28 May 2015 00:06 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146571B2B02 for <jose@ietfa.amsl.com>; Wed, 27 May 2015 17:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZJsYyreG3tF for <jose@ietfa.amsl.com>; Wed, 27 May 2015 17:06:52 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128FD1B2AFB for <jose@ietf.org>; Wed, 27 May 2015 17:06:52 -0700 (PDT)
Received: from BL2PR03MB436.namprd03.prod.outlook.com (10.141.92.26) by BL2PR03MB193.namprd03.prod.outlook.com (10.255.230.141) with Microsoft SMTP Server (TLS) id 15.1.184.10; Thu, 28 May 2015 00:06:51 +0000
Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB436.namprd03.prod.outlook.com (10.141.92.26) with Microsoft SMTP Server (TLS) id 15.1.184.10; Thu, 28 May 2015 00:06:49 +0000
Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0184.009; Thu, 28 May 2015 00:06:49 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "jose@ietf.org" <jose@ietf.org>
Thread-Topic: JWS Signing Input Options specification enabling non-base64-encoded payloads when safe to do so
Thread-Index: AdCY2jEf91vEFS6tRNCLIbp4vatLVg==
Date: Thu, 28 May 2015 00:06:49 +0000
Message-ID: <BL2PR03MB433040EE90372FAC663B479F5CA0@BL2PR03MB433.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [2001:4898:80e0:ee43::2]
x-microsoft-exchange-diagnostics: 1; BL2PR03MB436; 3:C2KVW3WjhLFDHxu8dfFSEPUNHILEn3q8UQdJe8vFfuXTh6uTCEaCtUkjD6BLIOLgXJ/d8nJQMxhTcXr88AdsSE8xU7s7noeekqqR/RqqN4BZmEzkVdN2UFMaG59FUR8ztJbXbrfrI37ozpX4s5MNPA==; 10:3MC4ODvEAoUsZNLWKlLKmfhFN4YrodGaF3eJhpIhIOsDabVN5J1Psg+R6R+tXYr0J+sug2iGHE6ht2KWOG17+ucErmPNA+Duu3rdNfInvyQ=; 6:ceG2sRLwN7XnggmBdzbdI+gpdKTS8g2jyB7TeJElkxJTq4wQTLH36SNLrTWLXE3m
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB436; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB193;
x-microsoft-antispam-prvs: <BL2PR03MB43611EAD05A5EDA4645F39FF5CA0@BL2PR03MB436.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:BL2PR03MB436; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB436;
x-forefront-prvs: 0590BBCCBC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(19609705001)(122556002)(450100001)(77156002)(62966003)(106356001)(76576001)(19580395003)(40100003)(19617315012)(2501003)(92566002)(5001860100001)(46102003)(5001830100001)(87936001)(102836002)(77096005)(68736005)(15975445007)(86362001)(4001540100001)(5002640100001)(2900100001)(97736004)(74316001)(81156007)(189998001)(19300405004)(101416001)(64706001)(16236675004)(230783001)(2656002)(99286002)(2351001)(19625215002)(33656002)(86612001)(229853001)(561944003)(110136002)(105586002)(54356999)(107886002)(5001960100002)(50986999)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB436; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BL2PR03MB433040EE90372FAC663B479F5CA0BL2PR03MB433namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 00:06:49.7910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB436
X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB193; 2:WDtVP+h7BYoFHQc+ywyYbxtL/v645dicjt7UAvX/r1XZe8IceV0nGPot5UilEfhW; 2:1DP/17HBUZ926kJRvrRfqoLBKWHqbs8VGtnMecWijfmKNCjSpo5vAaio7zo5ETzHWJfE1viHXtopqdJbAvSaG+SUGr35XbYHjskROloD6TgC8ZpuYWyEdorMM6nneSgoFNhfYTBp3Da9JAv+zxZpsw==; 9:xRqRz0XwEcJ4123cVJ68M4ypY7zZQwBPMCcruzMPla/T2xd6p0Wj/ud3YiCDJSXzBcN/qVG0OrSzpsTdKSGoVK4FW8L/07hjqSbTG671fz3wZoKhf4samy4skLzvh9yxO+xWBPkDwcZHcfrBF9Qxlg==
X-OriginatorOrg: microsoft.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/IkZ1QqnhATL4C0qTyixqqUb0SKI>
Subject: [jose] JWS Signing Input Options specification enabling non-base64-encoded payloads when safe to do so
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 00:06:55 -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.