Sent from my iPhone

> On Sep 29, 2014, at 6:42 PM, Mike Jones <[email protected]> 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 protected]] 
> Sent: Sunday, September 28, 2014 2:30 PM
> To: The IESG
> Cc: [email protected]; 
> [email protected]
> 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?  Also, is there space allocated 
for the "." Separators or is that not necessary?  

Thanks,
Kathleen 
> == Section 7 ==
>  
> Do we use [email protected]? I usually use [email protected].
>  
> == 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
>  
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to