RE: Issue with ECC section references in XML Signature 1.1 editors draft

Fredrick

I agree with your recommendation, keep the ECC-ALGS reference.  

Regards, Cynthia Martin/MITRE

-----Original Message-----
From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On
Behalf Of Frederick.Hirsch@nokia.com
Sent: Monday, February 07, 2011 7:23 AM
To: mnystrom@microsoft.com
Cc: Frederick.Hirsch@nokia.com; public-xmlsec@w3.org
Subject: Re: Issue with ECC section references in XML Signature 1.1 editors
draft

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
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>