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

Mike Jones <Michael.Jones@microsoft.com> Mon, 29 September 2014 22:19 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 1A2C61ACD32; Mon, 29 Sep 2014 15:19: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 RaBDcoLr7W5Q; Mon, 29 Sep 2014 15:19:33 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0D31ACD40; Mon, 29 Sep 2014 15:19:32 -0700 (PDT)
Received: from DM2PR0301MB1214.namprd03.prod.outlook.com (25.160.219.155) by DM2PR0301MB1181.namprd03.prod.outlook.com (25.160.217.143) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 22:19:04 +0000
Received: from BN3PR0301CA0081.namprd03.prod.outlook.com (25.160.152.177) by DM2PR0301MB1214.namprd03.prod.outlook.com (25.160.219.155) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 22:19:11 +0000
Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::190) by BN3PR0301CA0081.outlook.office365.com (2a01:111:e400:401e::49) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Mon, 29 Sep 2014 22:19:08 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Mon, 29 Sep 2014 22:19:08 +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; Mon, 29 Sep 2014 22:18:20 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Thread-Topic: Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)
Thread-Index: AQHP2M2p40kNJRGfoE2XYlz5+tEBApwYsvmQ
Date: Mon, 29 Sep 2014 22:18:19 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAA1160@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <20140925143306.27044.78134.idtracker@ietfa.amsl.com>
In-Reply-To: <20140925143306.27044.78134.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.32]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA1160TK5EX14MBXC288r_"
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)(13464003)(199003)(52044002)(377454003)(189002)(54356999)(97736003)(50986999)(76176999)(99396003)(6806004)(15975445006)(87936001)(68736004)(55846006)(2656002)(19580405001)(19580395003)(83322001)(44976005)(512874002)(84326002)(19625215002)(95666004)(64706001)(77096002)(86362001)(76482002)(230783001)(10300001)(16236675004)(120916001)(66066001)(92726001)(90102001)(21056001)(69596002)(106116001)(80022003)(31966008)(79102003)(81156004)(106466001)(74662003)(4396001)(107046002)(15202345003)(71186001)(20776003)(19300405004)(92566001)(83072002)(104016003)(85852003)(19617315012)(86612001)(81542003)(81342003)(46102003)(84676001)(33656002)(26826002)(85306004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1214; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1214;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 034902F5BC
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-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1181;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Po6UMnXSAoP5kg5E0ODt7-UFqsY
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-algorithms@tools.ietf.org" <draft-ietf-jose-json-web-algorithms@tools.ietf.org>
Subject: Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (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: Mon, 29 Sep 2014 22:19:36 -0000

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 [mailto:barryleiba@computer.org]
Sent: Thursday, September 25, 2014 7:33 AM
To: The IESG
Cc: jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-algorithms@tools.ietf.org
Subject: Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)



Barry Leiba has entered the following ballot position for

draft-ietf-jose-json-web-algorithms-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 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-algorithms/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



I have one comment.  I'm making it non-blocking, but I think it really does need to be clarified, so please chat with me about it:



-- Section 7.1 --



   The implementation requirements of an algorithm MAY be changed over

   time by the Designated Experts(s) as the cryptographic landscape

   evolves, for instance, to change the status of an algorithm to

   Deprecated, or to change the status of an algorithm from Optional to

   Recommended+ or Required.  Changes of implementation requirements are

   only permitted on a Specification Required basis, with the new

   specification defining the revised implementation requirements level.



1 (minor). The "MAY" does not refer to a protocol option, and I think it should not be a 2119 key word.



Agreed



2 (the real point). I don't understand how the two sentences relate to each other.  The first sentence seems to say that the DE(s) can change implementation requirements on their own.  The second says it has to be done using Specification Required (which doesn't really need to be said, as that's the policy for the registry anyway).



Which is it?  If it's Specification Required, then anyone can propose a change, using a specification, and the DE(s) will review that as they do any other registration request.



The intent is for both to be required – that a specification be written proposing the change and the designated experts approve the change.  I can look into a wording change to make this clearer when the document is next revised.



This comment also applies to Sections 7.4 and 7.6.



Noted.



                                                            -- Mike