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

Mike Jones <Michael.Jones@microsoft.com> Tue, 30 September 2014 22:21 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 972061ACC81; Tue, 30 Sep 2014 15:21:14 -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 H9acu7igwikd; Tue, 30 Sep 2014 15:21:11 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:745]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D50F1A1BE8; Tue, 30 Sep 2014 15:21:11 -0700 (PDT)
Received: from DM2PR03CA0026.namprd03.prod.outlook.com (10.141.96.25) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 22:20:47 +0000
Received: from BL2FFO11FD049.protection.gbl (2a01:111:f400:7c09::183) by DM2PR03CA0026.outlook.office365.com (2a01:111:e400:2428::25) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Tue, 30 Sep 2014 22:20:47 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD049.mail.protection.outlook.com (10.173.161.211) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 22:20:47 +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; Tue, 30 Sep 2014 22:20:05 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)
Thread-Index: AQHP22Nh/Ooxbo9Z6kW9ar3u5z04qZwYtUuwgABED4CAAQo0sIAAOEUA
Date: Tue, 30 Sep 2014 22:20:04 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAA7773@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <20140928212955.32419.90607.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAA14D8@TK5EX14MBXC288.redmond.corp.microsoft.com> <3BE06C3F-9D49-4BBE-9099-EFE795AE1CD9@gmail.com> <4E1F6AAD24975D4BA5B16804296739439BAA5AAF@TK5EX14MBXC288.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAA5AAF@TK5EX14MBXC288.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.70]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA7773TK5EX14MBXC288r_"
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)(377454003)(13464003)(164054003)(51444003)(24454002)(189002)(52044002)(199003)(50986999)(87936001)(80022003)(92566001)(44976005)(54356999)(10300001)(97736003)(46102003)(86612001)(31966008)(19580395003)(76176999)(92726001)(71186001)(66066001)(68736004)(85852003)(69596002)(86362001)(19580405001)(120916001)(15975445006)(6806004)(77096002)(21056001)(110136001)(99396003)(230783001)(20776003)(104016003)(2656002)(76482002)(85306004)(93886004)(64706001)(15202345003)(4396001)(16236675004)(106116001)(19617315012)(84326002)(81156004)(19625215002)(26826002)(19300405004)(107046002)(33656002)(84676001)(95666004)(106466001)(55846006)(512874002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; 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:BN3PR0301MB1204;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0350D7A55D
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/7kGBup06Pepcxx9K63tHphz8sus
Cc: "draft-ietf-jose-json-web-algorithms@tools.ietf.org" <draft-ietf-jose-json-web-algorithms@tools.ietf.org>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-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, 30 Sep 2014 22:21:14 -0000

A possible wording addition to remove any potential ambiguity is proposed inline below…

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Tuesday, September 30, 2014 11:45 AM
To: Kathleen Moriarty
Cc: Alissa Cooper; The IESG; jose-chairs@tools.ietf.org; jose@ietf.org; draft-ietf-jose-json-web-algorithms@tools.ietf.org
Subject: RE: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)

Replies to your questions are inline below, Kathleen.

From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Monday, September 29, 2014 7:42 PM
To: Mike Jones
Cc: Alissa Cooper; The IESG; jose-chairs@tools.ietf.org<mailto:jose-chairs@tools.ietf.org>; jose@ietf.org<mailto:jose@ietf.org>; draft-ietf-jose-json-web-algorithms@tools.ietf.org<mailto:draft-ietf-jose-json-web-algorithms@tools.ietf.org>
Subject: Re: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)



Sent from my iPhone

On Sep 29, 2014, at 6:42 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 2:30 PM
To: The IESG
Cc: jose-chairs@tools.ietf.org<mailto:jose-chairs@tools.ietf.org>; draft-ietf-jose-json-web-algorithms@tools.ietf.org<mailto:draft-ietf-jose-json-web-algorithms@tools.ietf.org>
Subject: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)



Alissa Cooper has entered the following ballot position for

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







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

COMMENT:

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



== Section 3.4 ==

"Signing and validation with the ECDSA P-384 SHA-384 and ECDSA P-521

  SHA-512 algorithms is performed identically to the procedure for

  ECDSA P-256 SHA-256 -- just using the corresponding hash algorithms

  with correspondingly larger result values.  For ECDSA P-384 SHA-384,

  R and S will be 384 bits each, resulting in a 96 octet sequence.  For

  ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a

  132 octet sequence."



For the ECDSA P-521 SHA-512 case, how does the result amount to 132 octets? Is there padding inserted into R and S?



The P-521 curve uses 521-bit R and S values.  It takes 66 octets to represent 521 bits.  There are two 66-octet values, hence 132 octets.


Mike,

I may be missing something too... It looks like there is a little padding as the info in the draft gets to 65.1 as opposed to 66.  I think that's what Alissa was getting at.  How is that handled?

You’re right that there is 7 bits of zero-valued padding in the highest-order bits of the octet sequence representations of both values when using 521-bit integers.  This allows each to be represented in separate octet sequences that represent big-endian integers.  This padding is specified in [SEC1].  Step two of this section includes this text about the integer-to-octet string conversion:

       The values R
       and S are represented as octet sequences using the Integer-to-
       OctetString Conversion defined in Section 2.3.7<https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#section-2.3.7> of SEC1 [SEC1<https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#ref-SEC1>]
       (in big endian octet order).


Thinking about it some more, we could add the following parenthetical remark after the sentence “For ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a 132 octet sequence” to remove any possible ambiguity:



(Note that the Integer-to-OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1] used to represent R and S as octet sequences adds zero-valued high-order padding bits when needed to round the size up to a multiple of 8 bits; thus, each 521-bit integer is represented using 528 bits in 66 octets.)



Would that work for people?  It may be overkill, given the reference to SEC1 two paragraphs earlier, but it should be 100% clear.

Also, is there space allocated for the "." Separators or is that not necessary?

The base64url encoded signature value contains no “.” character.  The binary signature value consists of the concatenation of the two octet sequences representing R and S, which are of a known fixed length for each particular curve.

Thanks,
Kathleen

== Section 7 ==



Do we use iesg@iesg.org<mailto:iesg@iesg.org>? I usually use iesg@ietf.org<mailto:iesg@ietf.org>.



== Section 8.4 ==

"An Initialization Vector value MUST never be used multiple times with

   the same AES GCM key."



I think what was intended here was s/MUST never/MUST NOT/



Agreed.  To keep the same level of emphasis, I propose to change “MUST never” to “MUST NOT ever”.



                                                            -- Mike