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

"Manger, James" <> Thu, 17 December 2015 02:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DEB841ABD3E; Wed, 16 Dec 2015 18:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fA_1aPp5VRV6; Wed, 16 Dec 2015 18:07:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A9B2B1ABD3D; Wed, 16 Dec 2015 18:07:58 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.20,438,1444654800"; d="scan'208";a="48149940"
Received: from unknown (HELO ([]) by with ESMTP; 17 Dec 2015 13:07:55 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8017"; a="52287626"
Received: from ([]) by with ESMTP; 17 Dec 2015 13:07:56 +1100
Received: from ([]) by ([fe80::4054:1e02:ef57:8da6%27]) with mapi; Thu, 17 Dec 2015 13:07:56 +1100
From: "Manger, James" <>
To: Mike Jones <>, Robert Sparks <>, General Area Review Team <>, "" <>, Ben Campbell <>, Benoit Claise <>
Date: Thu, 17 Dec 2015 13:07:54 +1100
Thread-Topic: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 02:08:01 -0000

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