I think the suggested change below would be helpful. Thanks, Alissa On Sep 30, 2014, at 3:20 PM, Mike Jones <[email protected]> wrote:
> A possible wording addition to remove any potential ambiguity is proposed > inline below… > > From: Mike Jones [mailto:[email protected]] > Sent: Tuesday, September 30, 2014 11:45 AM > To: Kathleen Moriarty > Cc: Alissa Cooper; The IESG; [email protected]; [email protected]; > [email protected] > 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 protected]] > Sent: Monday, September 29, 2014 7:42 PM > To: Mike Jones > Cc: Alissa Cooper; The IESG; [email protected]; [email protected]; > [email protected] > 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 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? > > 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 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
