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

Mike Jones <> Sun, 13 December 2015 02:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E8DC1A878C; Sat, 12 Dec 2015 18:32:53 -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 1rDBCSgbyLkJ; Sat, 12 Dec 2015 18:32:49 -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 D74A11A8712; Sat, 12 Dec 2015 18:32:48 -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=ig0iqq0jR0b5LShx+8FZ67tD/LHjceEvMWWBSg0JZCk=; b=O5WCt4UyJlhUCMgn5ryXoze0UiclgIJpIWD8TCdSaHuhPoTQ0ALXs4rlaNdf/T+yZtMVI4etIuICKJ9/WdmzKOnxjjnpsCkZjEeobGBqg7Z2e30Qno1AnuyN0xaipZ+EExi1d9ACm8w58tuRvAlnXMGNksF3VT1nS9QrEV3XwvQ=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.355.16; Sun, 13 Dec 2015 02:32:45 +0000
Received: from ([]) by ([]) with mapi id 15.01.0355.012; Sun, 13 Dec 2015 02:32:45 +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: AQHRLscgygv2Fq2BG0WOTjCzBNezWJ7IOL9A
Date: Sun, 13 Dec 2015 02:32:45 +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; BY2PR03MB442; 5:j8dsbg8XFtdmKPXM1+Xk0X1WEYglFPo2rHySZKvlb7j2BoBK+iael1Tg64rl1MMEnwY4x/pcFOFJxvNXEEt6nAUvR8/LlOC86OHWFLb61AmUtwHw/JigEmgPCz67d2aZrkI7rDUSZJzBsWy/Frtm0A==; 24:2sfUYtwGRuOUgCIgg848aUBsWPdccvsSHF56uSZoOaykLZccnje5aghlmqzGeEBBd0Fe9CvrxOCODZ46RfYGhsB5EsGILK5NAiWaZwvFUa0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442;
x-forefront-prvs: 07891BF289
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(43784003)(189002)(199003)(13464003)(51914003)(76176999)(105586002)(99286002)(106116001)(106356001)(74316001)(11100500001)(50986999)(86612001)(2201001)(5002640100001)(33656002)(5001770100001)(81156007)(97736004)(189998001)(107886002)(5001960100002)(101416001)(19580395003)(86362001)(5005710100001)(19580405001)(5003600100002)(8990500004)(10400500002)(10290500002)(230783001)(5004730100002)(10090500001)(15975445007)(2950100001)(2900100001)(5008740100001)(54356999)(77096005)(87936001)(76576001)(2501003)(66066001)(92566002)(40100003)(1220700001)(586003)(3846002)(102836003)(6116002)(1096002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: 13 Dec 2015 02:32:45.7239 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
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: Sun, 13 Dec 2015 02:32:53 -0000

Hi Robert.  Thanks for the useful review.  Replies are inline below...

> -----Original Message-----
> From: Robert Sparks []
> Sent: Friday, December 4, 2015 11:08 AM
> To: General Area Review Team <>;;
> Subject: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-jose-jws-signing-input-options-06
> Reviewer: Robert Sparks
> Review Date: 4Dec2015
> IETF LC End Date: 9Dec2015
> IESG Telechat date: 17Dec2015
> Summary: Almost ready for publication as Proposed Standard, but with a
> minor issue that should be addressed before publication.
> Minor issues:
> This document explicitly provides a way for interoperability to fail, but does
> not motivate _why_ leaving this failure mode in the protocol is a good
> tradeoff.
> Specifically, as the security considerations section points out, it is possible for
> an existing implementation to receive a JWS that has b64=false, which it will
> ignore as an unknown parameter, and (however
> unlikely) successfully decode the payload, and hence believe it has a valid
> JWS that is not what was sent.
> The idea that this failure can be avoided by making sure the endpoints all
> play nice through some unspecified agreement is dangerous.
> Specifically, I don't think you can rule out the case that the JWS escapes the
> controlled set of actors you are positing in option 1 from the list in the
> security considerations..
> 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. 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