Return-Path: 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 A55A61A87A0; Tue, 14 Oct 2014 05:42:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ihcuShRHo8TF; Tue, 14 Oct 2014 05:41:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803991A879F; Tue, 14 Oct 2014 05:41:59 -0700 (PDT) Received: from BY2PR03CA064.namprd03.prod.outlook.com (10.141.249.37) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:41:57 +0000 Received: from BN1BFFO11FD036.protection.gbl (2a01:111:f400:7c10::1:153) by BY2PR03CA064.outlook.office365.com (2a01:111:e400:2c5d::37) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Tue, 14 Oct 2014 12:41:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD036.mail.protection.outlook.com (10.58.144.99) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:41:55 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:41:11 +0000 From: Mike Jones To: Alissa Cooper Thread-Topic: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT) Thread-Index: Ac/nrB2bBPmZ0y+CT/+DVOE1mgAY2Q== Date: Tue, 14 Oct 2014 12:41:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D126@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_4E1F6AAD24975D4BA5B16804296739439BB0D126TK5EX14MBXC286r_" 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)(43784003)(377454003)(199003)(164054003)(189002)(24454002)(51444003)(13464003)(52044002)(97736003)(71186001)(66066001)(64706001)(20776003)(92566001)(86362001)(86612001)(92726001)(84676001)(16236675004)(69596002)(15975445006)(68736004)(512954002)(81156004)(107046002)(106466001)(54356999)(95666004)(99396003)(80022003)(15843345004)(46102003)(15202345003)(50986999)(19300405004)(19580405001)(19580395003)(6806004)(44976005)(21056001)(77096002)(120916001)(19625215002)(85852003)(31966008)(230783001)(26826002)(76482002)(4396001)(19617315012)(85306004)(110136001)(104016003)(2656002)(87936001)(55846006)(84326002)(85806002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX: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: 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/u39ooXypD-ztO2ceXyUnpBtaOzE Cc: "draft-ietf-jose-json-web-algorithms@tools.ietf.org" , Kathleen Moriarty , "jose-chairs@tools.ietf.org" , IESG , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:42:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB0D126TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All these comments have been addressed in the -34 drafts, including changin= g from iesg@iesg.org to iesg@ietf.org. Thanks again, -- Mike From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Wednesday, October 01, 2014 11:10 AM To: Mike Jones Cc: Kathleen Moriarty; IESG; jose-chairs@tools.ietf.org; jose@ietf.org; dra= ft-ietf-jose-json-web-algorithms@tools.ietf.org Subject: Re: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algor= ithms-33: (with COMMENT) I think the suggested change below would be helpful. Thanks, Alissa On Sep 30, 2014, at 3:20 PM, Mike Jones > wrote: A possible wording addition to remove any potential ambiguity is proposed i= nline 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-algor= ithms-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; 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-algor= ithms-33: (with COMMENT) Sent from my iPhone On Sep 29, 2014, at 6:42 PM, Mike Jones > wrote: Thanks for your review, Alissa. I've added the working group to this threa= d 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; draft-ie= tf-jose-json-web-algorithms@tools.ietf.org Subject: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithm= s-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 introduc= tory 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: ---------------------------------------------------------------------- =3D=3D Section 3.4 =3D=3D "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 represe= nt 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 a= s 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-ord= er bits of the octet sequence representations of both values when using 521= -bit integers. This allows each to be represented in separate octet sequen= ces 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 of SEC1 [SEC1= ] (in big endian octet order). Thinking about it some more, we could add the following parenthetical remar= k after the sentence "For ECDSA P-521 SHA-512, R and S will be 521 bits eac= h, resulting in a 132 octet sequence" to remove any possible ambiguity: (Note that the Integer-to-OctetString Conversion defined in Section 2.3.7 o= f 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 octe= ts.) Would that work for people? It may be overkill, given the reference to SEC= 1 two paragraphs earlier, but it should be 100% clear. Also, is there space allocated for the "." Separators or is that not necess= ary? The base64url encoded signature value contains no "." character. The binar= y 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 =3D=3D Section 7 =3D=3D Do we use iesg@iesg.org? I usually use iesg@ietf.org<= mailto:iesg@ietf.org>. =3D=3D Section 8.4 =3D=3D "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 neve= r" to "MUST NOT ever". -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439BB0D126TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All these comments have b= een addressed in the -34 drafts, including changing from iesg@iesg.org to iesg@ietf.org.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks again,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: Alissa C= ooper [mailto:alissa@cooperw.in]
Sent: Wednesday, October 01, 2014 11:10 AM
To: Mike Jones
Cc: Kathleen Moriarty; IESG; jose-chairs@tools.ietf.org; jose@ietf.o= rg; draft-ietf-jose-json-web-algorithms@tools.ietf.org
Subject: Re: Alissa Cooper's No Objection on draft-ietf-jose-json-we= b-algorithms-33: (with COMMENT)

 

I think the suggested change below would be helpful.=

Thanks,

Alissa

 

On Sep 30, 2014, at 3:20 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:



A possible wording additi= on to remove any potential ambiguity is proposed inline below…=

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Tuesday, Sep= tember 30, 2014 11:45 AM
To: Kathleen Moria= rty
Cc: Alissa Cooper;= The IESG; jose-chairs= @tools.ietf.org; jose@ietf.org; draft-ietf-jose-json-web-algor= ithms@tools.ietf.org
Subject: RE: Aliss= a Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with CO= MMENT)

 

Replies to your questions= are inline below, Kathleen.

 

From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
Sent: Monday, Sept= ember 29, 2014 7:42 PM
To: Mike Jones
Cc: Alissa Cooper;= The IESG; jose-chairs= @tools.ietf.org; jose@ietf.org; draft-ietf-jose-json-web-algor= ithms@tools.ietf.org
Subject: Re: Aliss= a Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with CO= MMENT)

 



Sent from my iPhone


On Sep 29, 2014, at 6:42 PM, Mike Jones <Michael.Jones@microsoft.co= m> wrote:

Thanks for your review, A= lissa.  I’ve added the working group to this thread so they're a= ware 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;&nb= sp;draft-ietf-jose-json-web-algorithms@t= ools.ietf.org
Subject: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithm= s-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 subjec= t line intact and reply to all email addresses included in the To and CC li= nes. (Feel free to cut this introductory paragraph, however.)

 

 

for more information about IESG DISCUSS= and COMMENT positions.

 

 

The document, along with other ballot p= ositions, can be found here:

 

 

 

---------------------------------------= -------------------------------

COMMENT:

---------------------------------------= -------------------------------

 

=3D=3D Section 3.4 =3D=3D

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

  SHA-512 algorithms is performed = identically to the procedure for

  ECDSA P-256 SHA-256 -- just usin= g the corresponding hash algorithms

  with correspondingly larger resu= lt values.  For ECDSA P-384 SHA-384,

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

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

  132 octet sequence."

 

For the ECDSA P-521 SHA-512 case, how d= oes 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.  T= here are two 66-octet values, hence 132 octets.

 

Mike,

 

I may be missing something too... It looks like ther= e is a little padding as the info in the draft gets to 65.1 as opposed to 6= 6.  I think that's what Alissa was getting at.  How is that handl= ed?

 

You’re right that t= here is 7 bits of zero-valued padding in the highest-order bits of the octe= t sequence representations of both values when using 521-bit integers. = ; This allows each to be represented in separate octet sequences that repres= ent big-endian integers.  This padding is specified in [SEC1].  S= tep two of this section includes this text about the integer-to-octet strin= g conversion:

 

    &nbs= p;  The values R

    &nbs= p;  and S are represented as octet sequences using the Integer-to-

    &nbs= p;  OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1]

    &nbs= p;  (in big endian octet order).=

 

Thinking about it some mo= re, we could add the following parenthetical remark after the sentence R= 20;For ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a 132 oct= et sequence” to remove any possible amb= iguity:

 

(Note that the Integer-to= -OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1] used to rep= resent 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; thu= s, each 521-bit integer is represented using 528 bits in 66 octets.)=

 

Would that work for peopl= e?  It may be overkill, given the reference to SEC1 two paragraphs ear= lier, but it should be 100% clear.

 

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

 

The base64url encoded sig= nature value contains no “.” character.  The binary signat= ure value consists of the concatenation of the two octet sequences represen= ting R and S, which are of a known fixed length for each particular curve.

 

Thanks,

Kathleen 

=3D=3D Section 7 =3D=3D

 

Do we use iesg@iesg.org? I usually use iesg@ietf.org.

 

=3D=3D Section 8.4 =3D=3D

"An Initialization Vector value MU= ST never be used multiple times with

   the same AES GCM key."= ;

 

I think what was intended here was s/MU= ST never/MUST NOT/

 

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

 

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike=

 

 

--_000_4E1F6AAD24975D4BA5B16804296739439BB0D126TK5EX14MBXC286r_--