Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)

Mike Jones <> Tue, 30 September 2014 18:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E3D2A1A8781; Tue, 30 Sep 2014 11:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pDoNwXeo9fxE; Tue, 30 Sep 2014 11:52:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B52B51A879C; Tue, 30 Sep 2014 11:51:41 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 18:51:39 +0000
Received: from (2a01:111:f400:7c10::1:156) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 18:51:38 +0000
Received: from ([]) by ([]) 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)
Date: Tue, 30 Sep 2014 18:50:56 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA5BC2TK5EX14MBXC288r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; 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;; 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 ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)
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

-----Original Message-----
From: [] On Behalf Of Barry Leiba
Sent: Tuesday, September 30, 2014 9:44 AM
To: Mike Jones
Cc: The IESG;;;
Subject: Re: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-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.


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


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


                                                            Thanks again,

                                                            -- Mike