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

Mike Jones <Michael.Jones@microsoft.com> Tue, 14 October 2014 12:42 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 D96E71A87AC; Tue, 14 Oct 2014 05:42:36 -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, 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 jCznAMm1JFLy; Tue, 14 Oct 2014 05:42:29 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953D81A879F; Tue, 14 Oct 2014 05:42:28 -0700 (PDT)
Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by BL2PR03MB385.namprd03.prod.outlook.com (10.141.91.139) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:42:05 +0000
Received: from BY2FFO11FD046.protection.gbl (10.255.156.132) by CH1PR03CA011.outlook.office365.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 14 Oct 2014 12:42:04 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD046.mail.protection.outlook.com (10.1.15.170) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:42:04 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:41:36 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Alissa Cooper <alissa@cooperw.in>
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
Thread-Index: Ac/nrC3j0WCSG0OVTuucXCix8C0lig==
Date: Tue, 14 Oct 2014 12:41:36 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D163@TK5EX14MBXC286.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB0D163TK5EX14MBXC286r_"
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)(438002)(51914003)(164054003)(43784003)(24454002)(189002)(199003)(13464003)(52044002)(377454003)(20776003)(66066001)(68736004)(69596002)(19300405004)(85806002)(64706001)(77096002)(76482002)(107046002)(19580395003)(86362001)(54356999)(50986999)(44976005)(80022003)(6806004)(19580405001)(92566001)(2656002)(106466001)(99396003)(87936001)(85306004)(230783001)(85852003)(512954002)(81156004)(86612001)(46102003)(15975445006)(95666004)(71186001)(84326002)(84676001)(104016003)(97736003)(31966008)(33656002)(110136001)(19625215002)(26826002)(120916001)(19617315012)(92726001)(21056001)(4396001)(16236675004)(55846006)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB385; 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:BL2PR03MB385;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Exchange-Antispam-Report-Test: UriScan:;
X-Forefront-PRVS: 03648EFF89
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/qg2nLY3g5G56wTbNkRHfQotspU0
Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" <draft-ietf-jose-json-web-encryption@tools.ietf.org>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
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: <http://www.ietf.org/mail-archive/web/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: Tue, 14 Oct 2014 12:42:37 -0000

These comments are addressed in the -34 specification.  Thanks again for your review.

                                                            -- Mike

From: Alissa Cooper [mailto:alissa@cooperw.in]
Sent: Wednesday, October 01, 2014 11:10 AM
To: Mike Jones
Cc: IESG; jose-chairs@tools.ietf.org<mailto:jose-chairs@tools.ietf.org>; draft-ietf-jose-json-web-encryption@tools.ietf.org<mailto:draft-ietf-jose-json-web-encryption@tools.ietf.org>; jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)

Hi Mike,

On Sep 29, 2014, at 3:50 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:


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 [mailto:alissa@cooperw.in]
Sent: Sunday, September 28, 2014 7:23 PM
To: The IESG
Cc: jose-chairs@tools.ietf.org<mailto:jose-chairs@tools.ietf.org>; draft-ietf-jose-json-web-encryption@tools.ietf.org<mailto:draft-ietf-jose-json-web-encryption@tools.ietf.org>
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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== 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
   specifications."

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


Ah, ok. In the 4.1 text I didn't get the implied "both specifications that defined a parameter with the same name."
Thanks,
Alissa