Re: [jose] Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 681AC1ACD73; Mon, 29 Sep 2014 15:51:13 -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 FLxAbe8zRK_E; Mon, 29 Sep 2014 15:51:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04B0B1ACD68; Mon, 29 Sep 2014 15:51:10 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 22:51:01 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Mon, 29 Sep 2014 22:51:00 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Mon, 29 Sep 2014 22:51:00 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Mon, 29 Sep 2014 22:50:17 +0000
From: Mike Jones <>
To: Alissa Cooper <>, The IESG <>
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
Thread-Index: AQHP24xesYJHhmrJNkSOgd82FbZGZJwYtokg
Date: Mon, 29 Sep 2014 22:50:16 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA15F1TK5EX14MBXC288r_"
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)(199003)(377454003)(52044002)(51914003)(13464003)(189002)(55846006)(10300001)(33656002)(21056001)(76482002)(20776003)(64706001)(71186001)(85306004)(77096002)(69596002)(6806004)(81156004)(230783001)(19580405001)(84326002)(19580395003)(68736004)(99396003)(106466001)(106116001)(120916001)(95666004)(46102003)(80022003)(66066001)(15975445006)(26826002)(54356999)(19625215002)(76176999)(4396001)(2656002)(512874002)(31966008)(86362001)(50986999)(92566001)(107046002)(92726001)(44976005)(16236675004)(19300405004)(85852003)(19617315012)(15202345003)(84676001)(97736003)(87936001)(104016003)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB390;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB390;
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] Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (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:51:13 -0000

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

-----Original Message-----
From: Alissa Cooper []
Sent: Sunday, September 28, 2014 7:23 PM
To: The IESG
Subject: Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)

Alissa Cooper has entered the following ballot position for

draft-ietf-jose-json-web-encryption-33: 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 2 ==

It seems a bit odd that some of these terms are re-defined by this document rather than re-using existing definitions, e.g. from RFC 4949 (plaintext, ciphertext, etc.). Was that deliberate?

Thanks for the RFC 4949 reference.  I propose that we use those definitions, where applicable.

== Section 4.1 ==

"As indicated by the common registry, JWSs and JWEs share a common

   Header Parameter space; when a parameter is used by both

   specifications, its usage must be compatible between the


Since both the JWS and JWE specifications are on their way to becoming RFCs, would it make more sense to say "its usage is compatible between the specifications"? Or is this for the future when new parameters may get defined?

This text is applicable both to the current documents and to future registrations in the IANA JSON Web Signature and Encryption Header Parameters Registry.  The registration instructions include this text, reinforcing this requirement:
   The same Header Parameter name can be
   registered multiple times, provided that the parameter usage is
   compatible between the specifications.  Different registrations of
   the same Header Parameter name will typically use different Header
   Parameter Usage Location(s) values.

                                                            -- Mike