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

[Alissa Cooper <[e-mail]>]

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

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

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