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

Mike Jones <Michael.Jones@microsoft.com> Thu, 17 December 2015 00:59 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 668291A8831; Wed, 16 Dec 2015 16:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOIGrQkadqtH; Wed, 16 Dec 2015 16:59:40 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680231A8A7F; Wed, 16 Dec 2015 16:59:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qEzl/yZxeJiu633xEJDQQaDcIYcQ7TQ61gQjuRnRIQc=; b=KYSlGPgNk/dILOIFyitxtxeKwV4odLPslqXS/vCMzl9hVmLuXrm1R54LK0XUU9I+nwYuE0XCMHr/PFsgkMCp+eKXm2JieD+XeiLp2KSHq77g9LqasQu1IiPKTa3Cngp7M72+JheryJ+4dQUh1uie59Dso7b1AtawhWD4HHhPXUo=
Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB435.namprd03.prod.outlook.com (10.141.92.24) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 00:59:26 +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.0355.012; Thu, 17 Dec 2015 00:59:26 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Robert Sparks' <rjsparks@nostrum.com>, 'General Area Review Team' <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-jws-signing-input-options@ietf.org" <draft-ietf-jose-jws-signing-input-options@ietf.org>
Thread-Topic: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
Thread-Index: AQHRNriyEtD5dJ5ix0G8xIGsBx3uup7OWZ9A
Date: Thu, 17 Dec 2015 00:59:26 +0000
Message-ID: <BL2PR03MB4330B9CA12223F74F8358DDF5E00@BL2PR03MB433.namprd03.prod.outlook.com>
References: <5661E491.9050007@nostrum.com> <BY2PR03MB442B4D7B1E70A9957D43590F5EC0@BY2PR03MB442.namprd03.prod.outlook.com> <566DDF01.1020806@nostrum.com> <BY2PR03MB442BCE6CA07CC6EA7A86684F5ED0@BY2PR03MB442.namprd03.prod.outlook.com> <06f501d136b8$4d445020$e7ccf060$@augustcellars.com>
In-Reply-To: <06f501d136b8$4d445020$e7ccf060$@augustcellars.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: [188.92.133.18]
x-microsoft-exchange-diagnostics: 1; BL2PR03MB435; 5:wXOkzpM4WGWhzWRLtqt9CEeAGzUgD5E4/Eq6HgbMUf6U4ZAyZgRgBrFb4/RCTROi/kbYX/+/sgy4eYEKGO/LrKc5Dr/jLZ0k2x6F+IC7yCGCc4int3HtffYec434/QlrX59pLkadVVSOSi7SfSqQBw==; 24:KHalUdTwi7xs7ihIrOatEbfBFC+qpmd51mg8PA6nAYfywPC0K5YaEmWjpwPSdP3BM6SK2oaTqCQdSX6uPiQjlMrWn57ooeNdMI2xpXGfgTQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB435;
x-microsoft-antispam-prvs: <BL2PR03MB435F3B30D5F88CC15BD38A2F5E00@BL2PR03MB435.namprd03.prod.outlook.com>
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)(15975445007)(87936001)(2201001)(5001770100001)(5004730100002)(81156007)(50986999)(10090500001)(86362001)(10290500002)(93886004)(11100500001)(2950100001)(2501003)(5008740100001)(107886002)(97736004)(5003600100002)(10400500002)(86612001)(5002640100001)(76176999)(5001960100002)(189998001)(230783001)(5005710100001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB435; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com 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-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 00:59:26.7224 (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: <http://mailarchive.ietf.org/arch/msg/jose/-KpEsFgDQkDx3yeDB1CGGMqw64g>
Subject: Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Dec 2015 00:59:43 -0000

Hi Jim,

Please see my replies to Robert and Richard.  I believe they cover the point you're making below.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com] 
Sent: Monday, December 14, 2015 10:42 PM
To: Mike Jones <Michael.Jones@microsoft.com>om>; 'Robert Sparks' <rjsparks@nostrum.com>om>; 'General Area Review Team' <gen-art@ietf.org>rg>; ietf@ietf.org; jose@ietf.org; draft-ietf-jose-jws-signing-input-options@ietf.org
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Mike,

This is interesting from a couple of points.

Why would you have an application that uses "b64":false as a parameter.
This is longer and thus would appear to be undesirable from that perspective.  It might imply that the application is using both true and false for b64, but that is something that you have said is not recommended.

It would, of course, be perfectly acceptable to say that crit needs to be present only if b64 is true.  This would address your worry about it failing for the case of b64:false being included.

Jim

> -----Original Message-----
> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Sunday, December 13, 2015 8:05 PM
> To: Robert Sparks <rjsparks@nostrum.com>om>; General Area Review Team 
> <gen- art@ietf.org>gt;; ietf@ietf.org; jose@ietf.org;
draft-ietf-jose-jws-signing-input-
> options@ietf.org
> Subject: Re: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-
> 06
> 
> 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 [mailto:rjsparks@nostrum.com]
> Sent: Sunday, December 13, 2015 1:11 PM
> To: Mike Jones <Michael.Jones@microsoft.com>om>; General Area Review Team 
> <gen-art@ietf.org>rg>; ietf@ietf.org; jose@ietf.org;
draft-ietf-jose-jws-signing-
> input-options@ietf.org
> 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
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose