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

Mike Jones <> Mon, 29 September 2014 22:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2EACA1ACD5E; Mon, 29 Sep 2014 15:33:53 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UkX_O58xD4Zb; Mon, 29 Sep 2014 15:33:50 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4DA81ACD71; Mon, 29 Sep 2014 15:33:49 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 22:33:26 +0000
Received: from (2a01:111:f400:7c0c::116) by (2a01:111:e400:2c5d::47) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Mon, 29 Sep 2014 22:33:26 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Mon, 29 Sep 2014 22:33:26 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Mon, 29 Sep 2014 22:32:51 +0000
From: Mike Jones <>
To: Barry Leiba <>, The IESG <>
Thread-Topic: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)
Date: Mon, 29 Sep 2014 22:32:50 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA1268TK5EX14MBXC288r_"
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)(438002)(377454003)(13464003)(52044002)(189002)(199003)(106116001)(85306004)(95666004)(107046002)(19617315012)(64706001)(79102003)(104016003)(26826002)(84326002)(83072002)(85852003)(97736003)(76482002)(10300001)(4396001)(120916001)(84676001)(81156004)(106466001)(20776003)(71186001)(19625215002)(66066001)(21056001)(81342003)(33656002)(90102001)(77096002)(86362001)(15975445006)(69596002)(19580405001)(83322001)(6806004)(44976005)(68736004)(15202345003)(19580395003)(16236675004)(230783001)(86612001)(92566001)(92726001)(54356999)(55846006)(50986999)(76176999)(80022003)(74662003)(87936001)(31966008)(2656002)(99396003)(46102003)(81542003)(19300405004)(512874002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 034902F5BC
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, "" <>
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: Mon, 29 Sep 2014 22:33:53 -0000

Thanks for your review, Barry.  I’ve added the working group to this thread so they're aware of your comments.  Replies are inline below…

-----Original Message-----
From: Barry Leiba []
Sent: Thursday, September 25, 2014 8:24 AM
To: The IESG
Subject: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)

Barry Leiba has entered the following ballot position for

draft-ietf-jose-json-web-encryption-32: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to

for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:




-- Section 5.2 --

   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.

-- Section 7.2 --


      The "recipients" member value MUST be an array of JSON objects.

      Each object contains information specific to a single recipient.

      This member MUST be present, even if the array elements contain

      only the empty JSON object "{}" (which can happen when all Header

      Parameter values are shared between all recipients and when no

      encrypted key is used, such as when doing Direct Encryption).

I'm not sure how to read this.  Which of these is a correct version of the "recipients" member for the case in the second sentence?:

a.   "recipients": {}

b.   "recipients": [{}]

c.   "recipients": []

Can you word this to make the answer clearer in the text?

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?

-- Section 9 --

   o  If the object is using the JWS JSON Serialization or the JWE JSON

      Serialization, the members used will be different.  JWSs have a

      "signatures" member and JWEs do not.  JWEs have a "recipients"

      member and JWSs do not.

But you say that unrecognized members should be ignored, so an object that contains both a "signatures" member and a "recipients" member would be considered valid, but might be judged to be either one or the other, depending upon the order of the checking.  Does this matter?  Possibly not, but I wanted to ask.

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

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.

                                                            -- Mike