Return-Path: 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 E3D2A1A8781; Tue, 30 Sep 2014 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pDoNwXeo9fxE; Tue, 30 Sep 2014 11:52:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52B51A879C; Tue, 30 Sep 2014 11:51:41 -0700 (PDT) Received: from BY2PR03CA054.namprd03.prod.outlook.com (10.141.249.27) by CY1PR0301MB1211.namprd03.prod.outlook.com (25.161.212.145) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 18:51:39 +0000 Received: from BN1BFFO11FD039.protection.gbl (2a01:111:f400:7c10::1:156) by BY2PR03CA054.outlook.office365.com (2a01:111:e400:2c5d::27) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Tue, 30 Sep 2014 18:51:39 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD039.mail.protection.outlook.com (10.58.144.102) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 18:51:38 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.218]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Tue, 30 Sep 2014 18:50:57 +0000 From: Mike Jones To: Barry Leiba Thread-Topic: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT) Thread-Index: AQHP2NTJQPyBE5bxNUKFqOCbnT0lUJwYtPRAgAE08ACAACL8QA== Date: Tue, 30 Sep 2014 18:50:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAA5BC2@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <20140925152347.1954.5822.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAA1268@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA5BC2TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(43784003)(189002)(51704005)(13464003)(199003)(51914003)(51444003)(21056001)(68736004)(84676001)(76482002)(99396003)(106466001)(512954002)(66066001)(120916001)(10300001)(92726001)(97736003)(230783001)(54356999)(50986999)(19625215002)(26826002)(69596002)(77096002)(16236675004)(85306004)(81156004)(110136001)(20776003)(33656002)(92566001)(46102003)(64706001)(104016003)(80022003)(85852003)(84326002)(87936001)(6806004)(2656002)(55846006)(106116001)(19580395003)(31966008)(107046002)(95666004)(86362001)(76176999)(86612001)(4396001)(44976005)(19580405001)(15202345003)(15975445006)(71186001)(19300405004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1211; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1211; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0350D7A55D Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/2pt8eaCw0IwYMHj2CKB33wdxY0A Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose-chairs@tools.ietf.org" , The IESG , "jose@ietf.org" Subject: Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 18:52:12 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BAA5BC2TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry= Leiba Sent: Tuesday, September 30, 2014 9:44 AM To: Mike Jones Cc: The IESG; jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-encrypti= on@tools.ietf.org; jose@ietf.org Subject: Re: Barry Leiba's No Objection on draft-ietf-jose-json-web-encrypt= ion-32: (with COMMENT) >> Finally, note that it is an application decision which algorithms are >> acceptable in a given context. Even if a JWE can be successfully >> decrypted, unless the algorithms used in the JWE are acceptable to >> the application, it SHOULD reject the JWE. >> >> It's a small point, but what does it mean for an algorithm to be >> "acceptable", if not to define this very point? That is, if I accept >> (don't >> reject) a decryption with algorithm X, doesn't that *mean* that >> algorithm X is acceptable to me? > > Would you prefer that the first "are acceptable" be changed to "MAY be > used"? I believe that would remove any potential ambiguity. I did say it was a small point... Yes, with lowercase "may" (definitely not 2119 "MAY"), I think that'd be slightly better, so thanks. OK > The intent is b. I propose that the words "This member MUST be > present, even if the array elements contain only the empty JSON object > "{}"" be changed to "This member MUST be present with exactly one > array element per recipient, even if some or all of the array element > values are the empty JSON object {}". Would that be clearer? I think that would have helped me. Again, another small point. OK > There's a reason that the introductory paragraph contains the caveat: > > All these methods will yield the same result for all > legal input values; they may yield different results for malformed > inputs. > > I believe that this caveat covers the case of malformed (or at least > confused) input that you're describing. Therefore, I believe that no > specific edit is needed to the specification in response to this comment. Yes, that's fine; thanks for the answer. Barry Thanks again, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439BAA5BC2TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry= Leiba
Sent: Tuesday, September 30, 2014 9:44 AM
To: Mike Jones
Cc: The IESG; jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-encrypti= on@tools.ietf.org; jose@ietf.org
Subject: Re: Barry Leiba's No Objection on draft-ietf-jose-json-web-encrypt= ion-32: (with COMMENT)

 

>>    Finally, note that it = is an application decision which algorithms are

>>    acceptable in a given = context.  Even if a JWE can be successfully

>>    decrypted, unless the = algorithms used in the JWE are acceptable to

>>    the application, it SH= OULD reject the JWE.

>> 

>> It's a small point, but what does it mea= n for an algorithm to be

>> "acceptable", if not to define= this very point?  That is, if I accept

>> (don't

>> reject) a decryption with algorithm X, d= oesn't that *mean* that

>> algorithm X is acceptable to me?

> 

> Would you prefer that the first "are ac= ceptable" be changed to "MAY be

> used"?  I believe that would remov= e any potential ambiguity.

 

I did say it was a small point...  Yes, with= lowercase "may"

(definitely not 2119 "MAY"), I think th= at'd be slightly better, so thanks.

 

OK

 

> The intent is b.  I propose that the wo= rds "This member MUST be

> present, even if the array elements contain = only the empty JSON object

> "{}"" be changed to "Thi= s member MUST be present with exactly one

> array element per recipient, even if some or= all of the array element

> values are the empty JSON object {}".&n= bsp; Would that be clearer?

 

I think that would have helped me.  Again, a= nother small point.

 

OK

 

> There's a reason that the introductory parag= raph contains the caveat:

> 

>    All these methods will yie= ld the same result for all

>    legal input values; they m= ay yield different results for malformed

>    inputs.

> 

> I believe that this caveat covers the case o= f malformed (or at least

> confused) input that you're describing. = ; Therefore, I believe that no

> specific edit is needed to the specification= in response to this comment.

 

Yes, that's fine; thanks for the answer.

 

Barry

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      Thanks again,

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739439BAA5BC2TK5EX14MBXC288r_--