Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Mike Jones <> Thu, 17 December 2015 03:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A7AAD1AC82C; Wed, 16 Dec 2015 19:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BIJEJQqoM-zG; Wed, 16 Dec 2015 19:52:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83BB71AC529; Wed, 16 Dec 2015 19:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FqWsg3qY6J94n8VxI0/jhebdwQTDb5fOhWNCVRAb/AU=; b=XyttuhI3mMya77EaumG3oRWrIZCLszHB8/g0SNxRlG5n7HkKbUebtqS5XOoWON0yscq4EZvqcUCGWpGxtXU1073T/pLKAkPdEV7UeOkXL7r8+jOpX8nYEPWwENR7sxOHtiJ4gJsj1rPg0VAtPaXlzCe5h1YipnyNf+BMuwWXkLI=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 03:52:30 +0000
Received: from ([]) by ([]) with mapi id 15.01.0355.012; Thu, 17 Dec 2015 03:52:30 +0000
From: Mike Jones <>
To: "Manger, James" <>, Robert Sparks <>, General Area Review Team <>, "" <>, Ben Campbell <>, Benoit Claise <>
Thread-Topic: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
Thread-Index: AQHROG/CVGvdBvc6pkWammxFQfwa1J7Ob37A
Date: Thu, 17 Dec 2015 03:52:29 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BL2PR03MB436; 5:MHKhRbcxg5qUepevMngo5aZyfTKzgD+X2JUkRyop3tCKAqAFs/dJoiBwR73qjploTBzYVVy3dFryazzsvVBwm2AA4uC1n6jODOn5rz3mXyasdv2mKHCYDyXZTS1GOnfmgwnfnzOSxbatioblhJhqig==; 24:AqGG2e0MaBPmC3eZntLdvSVzgWOfWzlnfg/x2Py8MVAYeMdkGqQ694ci1wuoIfb38POWM9ELo24ApifhpRYahvD/pWlrVa/hTSFbTOk/v3I=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB436;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BL2PR03MB436; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB436;
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(377454003)(122556002)(40100003)(87936001)(77096005)(19580395003)(19580405001)(105586002)(1096002)(5008740100001)(586003)(3846002)(102836003)(6116002)(8990500004)(10090500001)(5005710100001)(10290500002)(10400500002)(86362001)(5004730100002)(92566002)(1220700001)(5003600100002)(86612001)(99286002)(2900100001)(106116001)(106356001)(33656002)(11100500001)(189998001)(97736004)(54356999)(66066001)(107886002)(81156007)(93886004)(5001960100002)(50986999)(5002640100001)(76176999)(5001770100001)(101416001)(230783001)(561944003)(76576001)(74316001)(2950100001)(2501003)(7059030)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB436;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 03:52:29.9578 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB436
Archived-At: <>
Subject: Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Dec 2015 03:52:35 -0000

James, as I see it, your proposal optimizes the Header Parameter requirements for the case in which the JWS isn't useful, rather than case in which it is.  This seems backwards, from an engineering point of view.

The new "crit" language in -08 already ensures clean failure in all the cases in which failure should occur.  There's then no need to include an extra parameter intended to cause a failure in cases in which the failure cannot occur.

				-- Mike

-----Original Message-----
From: Manger, James [] 
Sent: Thursday, December 17, 2015 3:08 AM
To: Mike Jones <>; Robert Sparks <>; General Area Review Team <>;; Ben Campbell <>; Benoit Claise <>
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Mike proposes the following:

   "Using "crit" with "b64"

   If a JWS using "b64" with a value of "false" might be processed by implementations not implementing this extension, then the "crit" Header Parameter MUST be included with "b64" in its set of values to cause such implementations to reject the JWS.  Conversely, if used in environments in which all participants implement this extension, then "crit" need not be included, since its inclusion would have no effect, other than increasing the JWS size and processing costs."

"crit":"xxx" is not needed once everyone understands xxx, for any value of xxx. This is the nature of "crit". draft-ietf-jose-jws-signing-input-options is precisely the case where "crit" should be used (new messages that can be misunderstood by old implementations). If it isn't used here, I doubt it will ever get used.

The fact Mike is pushing back so much on using "crit" despite being an author of the JWS spec defining "crit" is a sign that "crit" itself is a poor design for supporting extensibility. There were alternative versioning mechanisms discussed before JWS was published, but "crit" was picked.

Alternative suggested wording:

   The "crit" Header Parameter MUST be included with "b64" in its set of values to ensure the JWS is rejected (instead of being misinterpreted) by implementations that do not understand this specification.

If people need hope that the 13-char overhead ("crit":"b64",) will not last forever, perhaps add the following:

   A future specification might be able to relax this requirement if there is another mechanism to prevent misinterpretation, such as another "crit" value that also implies "b64" understanding, or the elimination of all old implementations.

Please don't add:

   "Implementations receiving JWSs using "b64" with a value of "false" will not be able to successful use those JWSs unless they support this extension, since they will be unable to obtain the payload value.  ... including "crit" is insufficient to enable the receiving implementation to use the JWS; that requires supporting this extension."

The last part is too obvious. The first part is either too obvious (if "successful" means from the senders point of view) or wrong (as the recipient thinks they have been successful when they have actually misinterpreted the message).

Please remove method 3: sending a payload with non-base64url chars. This makes too many assumptions about how a base64url-decoder will handle unexpected chars. Some will reject anything outside A-Za-z0-9-_, others will ignore whitespace, others will happily decode +/ and -_, others will ignore =, perhaps others ignore any unexpected chars.

James Manger