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 Friday, 4 February 2011 17:32:05 UTC