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

Mike Jones <> Thu, 17 December 2015 00:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E05321A8841; Wed, 16 Dec 2015 16:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EI9qpqLr4O8M; Wed, 16 Dec 2015 16:58:21 -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 5B5C81A894E; Wed, 16 Dec 2015 16:58:21 -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=1xaqmoulrb96dBVNO12TTMGKcqjJkrk+JIJ5RsaM+ds=; b=Dub6u1k/5T/wG4OSWnvLNY0zHSBVnEhK8Z3i0NFE3EwYy1MnL3X3dqX5jFfjDL4BCprkLn0you299/wnZo53XjlvoaBKu8BbWP78hwNQvWtxv++lDbOjSXTBmLWxM2fz7WwFGJqcAmZoTYB/NB2zbutp+p2zZifESOttTWkhbWE=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 00:58:19 +0000
Received: from ([]) by ([]) with mapi id 15.01.0355.012; Thu, 17 Dec 2015 00:58:18 +0000
From: Mike Jones <>
To: Robert Sparks <>, General Area Review Team <>, "" <>, "" <>, "" <>
Thread-Topic: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
Thread-Index: AQHRLscgygv2Fq2BG0WOTjCzBNezWJ7IOL9AgAE/XYCAAG/XcIAAzrwAgAOmocA=
Date: Thu, 17 Dec 2015 00:58:18 +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; BL2PR03MB435; 5:gRCu2V08xi5lHbzKBtqGfKePDYN0Li3KGyxpuW4r7E9E3elgqLq9uhERWk1SfsAl2OVOcFhVUG8E8Tk4tijqsWi0GfKH7akDWbPVmBaN7WYGbKoKTxJGxXjmRT0IDSAyxA7usYGtxr7QR2jeUn5Tqw==; 24:9bWHyMbxFKP2/ykj1q4mTuCLE3e8wE9AiPQ5aZpif3Q8TSmsJM4xwkGaUO/HW0jwb9IEbTO7NAyHOcjQabMiwqDl5VWQcMnLR6N7dKeHKIM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB435;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BL2PR03MB435; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB435;
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51914003)(43784003)(24454002)(51444003)(199003)(479174004)(189002)(377454003)(122556002)(33656002)(1096002)(40100003)(6116002)(102836003)(3846002)(92566002)(1220700001)(74316001)(76576001)(66066001)(99286002)(106356001)(101416001)(19580405001)(19580395003)(54356999)(586003)(105586002)(106116001)(2900100001)(77096005)(87936001)(2201001)(5001770100001)(5004730100002)(81156007)(50986999)(10090500001)(86362001)(10290500002)(93886004)(2950100001)(2501003)(5008740100001)(107886002)(97736004)(5003600100002)(10400500002)(86612001)(5002640100001)(76176999)(5001960100002)(189998001)(230783001)(5005710100001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB435;; 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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 00:58:18.4171 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB435
Archived-At: <>
Subject: Re: [Gen-art] 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 00:58:26 -0000

Thanks for your thoughtful comments, Robert.  Replies are inline below...

> -----Original Message-----
> From: Robert Sparks []
> Sent: Monday, December 14, 2015 5:12 PM
> To: Mike Jones <>om>; General Area Review Team
> <>rg>;;; draft-ietf-jose-jws-signing-
> Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
> Mike -
> No, this still doesn't explain why crit is not sufficient.

I'll plan on adding something along these lines to the draft to explain this:

"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.  If the JWS includes the "crit" Header Parameter with "b64" in the set of values, this will ensure that implementations not supporting this extension will reject the JWS, but including "crit" is insufficient to enable the receiving implementation to use the JWS; that requires supporting this extension."

> You are making a bare assertion that using crit doesn't achieve a). I think it
> does. Please explain (in the draft) why it doesn't.
> You are making me guess, but I think you are only trying to avoid having to
> include the few extra bits in the message. If you've _done_ the work of
> ensuring all the applications understand using b64 through some out-of-
> band magic, then including crit will just work. Are you pushing back on
> anything _but_ the packet-bloat in this case?
> If you _haven't_ done this out-of-band work, and you send to a receiver that
> understands the extension, then a) is achieved. If you send to a receiver that
> doesn't understand, things _should_ fail - arguably this also achieving a),
> though I suspect you are wincing at perhaps not having a clear path to
> recovery in this case?
> I really think this boils down to you not wanting to pay the extra few bits in
> the packet to say "crit".
> if that's not the case, please explain (and again, this needs to be in the draft,
> not just an email thread).

Yes, size matters, but that's not the primary thing that's in play here.  For the extension to be useful, all parties using the JWS must implement the extension, as explained in the new proposed text above.  And once the JWT with the extension is understood, "crit" adds nothing, because it's redundant.  That's why the draft doesn't require it.

But based on your comments and those of other reviewers, since there seems to be demand for it, I plan to add the following text, which I think gets at the heart of the issue you're discussing:

"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."

> RjS

				Thanks again, Robert,
				-- Mike

> On 12/13/15 10:04 PM, Mike Jones wrote:
> > Hi Robert,
> >
> > You asked "_WHY_ is crit not sufficient? I think that's the thing that's
> missing as motivation."
> >
> > There are two goals we're discussing, which are related:
> > (a) Having an application that uses "b64":false work.
> > (b) Having an application that receives a JWT with "b64":false not
> misinterpret the payload content.
> >
> > Including "crit":["b64"] would be sufficient to achieve (b), as it would cause
> the JWS to be rejected by implementations not supporting "b64".  But it does
> not achieve (a), since the JWS would be rejected.
> >
> > In contrast, using an implementation that understands "b64" achieves both
> (a) and (b) without needing to include "crit".  That's why it's not required.
> >
> > Does that make sense now?
> >
> > 				Best wishes,
> > 				-- Mike
> >
> > -----Original Message-----
> > From: Robert Sparks []
> > Sent: Sunday, December 13, 2015 1:11 PM
> > To: Mike Jones <>om>; General Area Review
> Team
> > <>rg>;;;
> >
> > Subject: Re: Gen-Art LC review:
> > draft-ietf-jose-jws-signing-input-options-06
> >
> > Cutting away a bit to focus on the question:
> >
> > On 12/12/15 8:32 PM, Mike Jones wrote:
> >> Hi Robert.  Thanks for the useful review.  Replies are inline below...
> >>
> >>> -----Original Message-----
> > <snip/>
> >>>
> >>> I would have been much more comfortable with a consensus to require
> 'crit'.
> >>> (Count me in the rough if this proceeds with crit being optional).
> >>>
> >>> I assume there is a strong reason to allow for option 1. Please add
> >>> the motivation for it to the draft, and consider adding a SHOULD use 'crit'
> >>> requirement if option 1 remains.
> >> It's a reasonable request to have the draft say why "crit" isn't required.
> My working draft adds the following new paragraph at the end of the
> security considerations section to do this.  Unless I hear objections, I'll plan
> on publishing an updated draft with the paragraph shortly.
> >>
> >> "Note that methods 2 and 3 are sufficient to cause JWSs using this
> extension to be rejected by implementations not supporting this extension
> but they are not sufficient to enable JWSs using this extension to be
> successfully used by applications.
> > The conclusion you draw here is not at all obvious.
> > _WHY_ is crit not sufficient? I think that's the thing that's missing as
> motivation.
> >
> >>    Thus, method 1 - requiring support for this extension - is the preferred
> approach and the only means for this extension to be practically useful to
> applications. Method 2 - requiring the use of <spanx
> style="verb">crit</spanx> - while theoretically useful to ensure that
> confusion between encoded and unencoded payloads cannot occur, is not
> particularly useful in practice, since method 1 is still required for the
> extension to be usable. When method 1 is employed, method 2 doesn't add
> any value and since it increases the size of the JWS, its use is not required by
> this specification."
> >>
> >>> Nits/editorial comments:
> >>>
> >>> In the security considerations, the last sentence of the first
> >>> paragraph needs to be simplified. I suggest replacing it with:
> >>>
> >>> "It then becomes the responsibility of the application to ensure
> >>> that payloads only contain characters that will not cause parsing
> >>> problems for the serialization used, as described in Section 5. The
> >>> application also incurs the responsibility to ensure that the
> >>> payload will not be modified during retransmission.
> >> I have simplified this in the manner that you suggested.
> >>
> >> 				Thanks again,
> >> 				-- Mike