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

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Oct 2014 11:10:18 -0700

I think the suggested change below would be helpful.
Thanks,
Alissa

On Sep 30, 2014, at 3:20 PM, Mike Jones <[email-masked]> wrote:

> A possible wording addition to remove any potential ambiguity is proposed inline below…
>  
> From: Mike Jones [mailto:[email-masked]] 
> Sent: Tuesday, September 30, 2014 11:45 AM
> To: Kathleen Moriarty
> Cc: Alissa Cooper; The IESG; [email-masked]; [email-masked]; [email-masked]
> 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:[email-masked]] 
> Sent: Monday, September 29, 2014 7:42 PM
> To: Mike Jones
> Cc: Alissa Cooper; The IESG; [email-masked]; [email-masked]; [email-masked]
> 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 <[email-masked]> 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:[email-masked]] 
> Sent: Sunday, September 28, 2014 2:30 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]
> 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 of SEC1 [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 [email-masked]? I usually use [email-masked].
>  
> == 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
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 14 Oct 2014 12:41:11 +0000

All these comments have been addressed in the -34 drafts, including changing from [email-masked]<mailto:[email-masked]> to [email-masked]<mailto:[email-masked]>.

                                                            Thanks again,
                                                            -- Mike

From: Alissa Cooper [mailto:[email-masked]]
Sent: Wednesday, October 01, 2014 11:10 AM
To: Mike Jones
Cc: Kathleen Moriarty; IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)

On Sep 30, 2014, at 3:20 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

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

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, September 30, 2014 11:45 AM
To: Kathleen Moriarty
Cc: Alissa Cooper; The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, September 29, 2014 7:42 PM
To: Mike Jones
Cc: Alissa Cooper; The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]]
Sent: Sunday, September 28, 2014 2:30 PM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Alissa Cooper's No Objection on draft-ietf-jose-json-web-algorithms-33: (with COMMENT)

== Section 3.4 ==

Mike,

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:

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 [email-masked]<mailto:[email-masked]>? I usually use [email-masked]<mailto:[email-masked]>.

== Section 8.4 ==

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

                                                            -- Mike