- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 4 Feb 2011 16:30:29 +0100
- To: <Frederick.Hirsch@nokia.com>
- Cc: Thomas Roessler <tlr@w3.org>, <public-xmlsec@w3.org>
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 Friday, 4 February 2011 15:30:34 UTC