- From: <Frederick.Hirsch@nokia.com>
- Date: Mon, 7 Feb 2011 12:22:48 +0000
- To: <mnystrom@microsoft.com>
- CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
Thanks I thought about changing "ECC-ALGS" to RFC6090 but did not for two reasons 1. many of our security references have a handle other that the RFC 2. when an RFC is obsoleted with a new RFC number we cannot go and change all the references, so ECC-ALGS is neutral to RFC number. I suggest we keep as ECC-ALGS regards, Frederick Frederick Hirsch Nokia On Feb 6, 2011, at 11:05 PM, ext Magnus Nystrom wrote: > Frederick, > I have the following suggestions: > > - 4.5.2.3: > > Change: > > Domain parameters can be encoded explicitly using the ECParameters element or by reference using the NamedCurve element. A named curve is specified through the URI attribute. For named curves that are identified by OIDs, such as those defined in [RFC3279][RFC4055], and [ECC-ALGS], the OID should be encoded according to [URN-OID]. Conformant applications must support the NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7. > > To: > > Domain parameters can be encoded explicitly using the ECParameters element or by reference using the NamedCurve element. A named curve is specified through the URI attribute. For named curves that are identified by OIDs, such as those defined in [RFC3279] and [RFC4055], the OID should be encoded according to [URN-OID]. Conformant applications must support the NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7. > > Change: > > 1.Convert the elliptic curve point (x,y) to an octet string as specified in Section 2.3.3 of [ECC-ALGS]. Support for Elliptic-Curve-Point-to-Octet-String conversion without point compression is required. > > To: > > 1.Convert the elliptic curve point (x,y) to an octet string by first converting the field elements x and y to octet strings as specified in Section 6.2 of [ECC-ALGS], and then prepend the concatenated result of the conversion with 0x04. Support for Elliptic-Curve-Point-to-Octet-String conversion without point compression is required. > > - 4.5.2.3.1: > > Change: > > 2.The Curve element specifies the coefficients a and b of the elliptic curve E. Each coefficient is first converted from a field element to an octet string as specified in section 2.3.5 of [ECC-ALGS], then the resultant octet string is encoded in base64. > > To: > > 2.The Curve element specifies the coefficients a and b of the elliptic curve E. Each coefficient is first converted from a field element to an octet string as specified in section 6.2 of [ECC-ALGS], then the resultant octet string is encoded in base64. > > Change: > > 6.The ValidationData element is an optional element that specifies the hash algorithm used to generate the elliptic curve E and the base point G verifiably at random. It also specifies the seed that was used to generate the curve and the base point. When verifiably random curves and base points are used, they shall be generated as described in Section 3.1.3 of [ECC-ALGS]. > > To: > > 6.The ValidationData element is an optional element that specifies the hash algorithm used to generate the elliptic curve E and the base point G verifiably at random. It also specifies the seed that was used to generate the curve and the base point. When verifiably random curves and base points are used, they shall be generated as described in [ANSI-X9.62]. > > Comment: Either we strike the last sentence, or we refer to ANSI X9.62. RFC 6090 does not appear to cover curve generation verifiably at random. > > In addition, for consistency, I suggest that the reference [ECC-ALGS] is changed to [RFC6090]. > > -- Magnus > > >> -----Original Message----- >> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] >> On Behalf Of Frederick.Hirsch@nokia.com >> Sent: Friday, February 04, 2011 9:31 AM >> To: Magnus Nystrom >> Cc: Frederick.Hirsch@nokia.com; tlr@w3.org; public-xmlsec@w3.org >> Subject: Re: Issue with ECC section references in XML Signature 1.1 editors draft >> >> Magnus >> >> Can you please review the text in question and see if the sections I suggested >> are adequate. I'm not sure they capture everything needed. >> >> regards, Frederick >> >> Frederick Hirsch >> Nokia >> >> >> >> On Feb 4, 2011, at 12:24 PM, ext Magnus Nystrom wrote: >> >>> Good catch, Frederick. But I'd definitely argue for staying with 6090 and >> adjusting section numbers and modifying text as required. >>> -- Magnus >>> >>>> -----Original Message----- >>>> From: public-xmlsec-request@w3.org >>>> [mailto:public-xmlsec-request@w3.org] >>>> On Behalf Of Thomas Roessler >>>> Sent: Friday, February 04, 2011 7:30 AM >>>> To: Frederick.Hirsch@nokia.com >>>> Cc: Thomas Roessler; public-xmlsec@w3.org >>>> Subject: Re: Issue with ECC section references in XML Signature 1.1 >>>> editors draft >>>> >>>> I'd lean toward keeping the reference to RFC 6090 and adjusting the >>>> section numbers. >>>> -- >>>> Thomas Roessler, W3C <tlr@w3.org> (@roessler) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 4 Feb 2011, at 16:24, <Frederick.Hirsch@nokia.com> wrote: >>>> >>>>> In reviewing the XML Signature 1.1 editors draft I notice that the >>>>> section >>>> references to the Elliptic Curve Algorithm definitions no longer are >>>> correct, given that we changed the reference from SECG1 to ECC-ALGS. >>>> It seems ok in XML Encryption 1.1 since it is a more general reference. >>>>> >>>>> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html >>>>> >>>>> In particular, the following seem incorrect >>>>> >>>>> In "4.5.2.3 The ECKeyValue Element": >>>>> >>>>> "Convert the elliptic curve point (x,y) to an octet string as >>>>> specified in Section >>>> 2.3.3 of [ECC-ALGS]." >>>>> >>>>> In "4.5.2.3.1 Explicit Curve Parameters": >>>>> >>>>> "The Curve element specifies the coefficients a and b of the elliptic curve E. >>>> Each coefficient is first converted from a field element to an octet >>>> string as specified in section 2.3.5 of [ECC-ALGS], then the >>>> resultant octet string is encoded in base64." >>>>> >>>>> "The ValidationData element is an optional element that specifies >>>>> the hash >>>> algorithm used to generate the elliptic curve E and the base point G >>>> verifiably at random. It also specifies the seed that was used to >>>> generate the curve and the base point. When verifiably random curves >>>> and base points are used, they shall be generated as described in Section >> 3.1.3 of [ECC-ALGS]." >>>>> >>>>> The section references are clearly incorrect and the sections in >>>>> ECC-ALGS that >>>> possibly could correspond don't seem to have the same level of detail (e.g. >>>> section 6 in ECC-ALGS versus 2.3.3 and 2.3.5, and ECC-ALGS Appendix B >>>> versus section 3.1.3). >>>>> >>>>> What should we do here, restore the reference to SECG1, change >>>>> section >>>> references for those I suggest in ECC-ALGS, or revise this text? >>>>> >>>>> Please review and indicate what we should do for these three cases. >>>>> We >>>> should fix this before CR. >>>>> >>>>> Thanks >>>>> >>>>> regards, Frederick >>>>> >>>>> Frederick Hirsch >>>>> Nokia >>>>> >>>>> [ECC-ALGS] http://www.rfc-editor.org/rfc/rfc6090.txt >>>>> >>>>> [SECG1] >>>>> SEC1: Elliptic Curve Cryptography, Version 2.0, Standards for >>>>> Efficient >>>> Cryptography Group, May 2009. URL: http://www.secg.org/download/aid- >>>> 780/sec1-v2.pdf >>>>> >>>> >>>> >>> >> >> >
Received on Monday, 7 February 2011 12:23:32 UTC