W3C home > Mailing lists > Public > public-xmlsec@w3.org > April 2009

Re: Elliptic Curve issue status

From: Magnus Nyström <magnus@rsa.com>
Date: Fri, 24 Apr 2009 17:11:46 -0700 (Pacific Daylight Time)
To: Frederick Hirsch <Frederick.Hirsch@nokia.com>
cc: XMLSec WG Public List <public-xmlsec@w3.org>
Message-ID: <Pine.WNT.4.64.0904241709280.4200@W-JNISBETTEST-1.tablus.com>
On Fri, 24 Apr 2009, Frederick Hirsch wrote:

> Thanks Magnus. The XML Encryption redline was out of date, which is why I did 
> not find it. I updated the redline. This means we can close ISSUE-103.
>
> Do you think we should keep ISSUE-92 open until we resolve the alternate 
> design decision?

I think that's reasonable.

> It looks to me like we should keep the text in both 6.4.3 and 4.4.2.3 since 
> they are not duplicates and seem appropriate for their sections, but what do 
> others think?

It is not a major point but Section 4 is about the _syntax_ and section 6 
is about the _algorithms_. It therefore seems to me to make more sense to 
have normative text regarding algorithms in section 6 and not in section 4 
(and in particular not have such text in two places - the text refers to 
the same curve but in two different ways). Others?

-- Magnus

> On Apr 23, 2009, at 11:11 AM, ext Magnus Nyström wrote:
>
>> For ISSUE-92: There wer no editorial action for "implicitCA" as we agreed
>> not to include this option. As for the separate ECDomainParameter type,
>> you may recall we discussed an alternate design but decided, for now, to
>> keep with Kelvin's original design. There is a note in XMLDsig about this.
>> 
>> As for ISSUE-103, new text is in XMLEnc 5.5.4: "Compliant implementations
>> are REQUIRED to support ECDH-ES key agreement using the P-256 prime curve
>> specified in Section D.2.3 of FIPS 186-3 [FIPS186-3]. (This is the same
>> curve that is REQUIRED in XMLDSIG 1.1 to be supported for the
>> ECDSAwithSHA256 algorithm.) It is further RECOMMENDED that implementations
>> also support the P-384 and P-521 prime curves for ECDH-ES; these curves
>> are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively."
>> 
>> Similar text is also in Section 6.4.3 of XMLDsig 1.1. However, I wonder if
>> the text in Section 4.4.2.3 of XMLDsig ("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.") should not be removed as the
>> section where the MUSTs/SHOULDs on algorithms really is 6.4.3 , whereas
>> 4.4.2.3 is about describing ECC key valus.
>> 
>> -- Magnus
>> 
>> On Tue, 21 Apr 2009, Frederick Hirsch wrote:
>> 
>>> Magnus
>>> 
>>> Are you able to confirm that the editorial actions for ISSUE-92 and 
>>> ISSUE-103
>>> are complete? Do you have pointers to where the draft has been updated?
>>> 
>>> Thanks
>>> 
>>> regards, Frederick
>>> 
>>> Frederick Hirsch
>>> Nokia
>>> 
>>> 
>>> 
>>> On Apr 21, 2009, at 9:32 AM, ext Magnus Nyström wrote:
>>> 
>>>> Frederick,
>>>> 
>>>> #92 and #93 are done and can be closed.
>>>> We had agreement on #103 and AFAICT the text has been included now in
>>>> XMLEnc 1.1 so this one should also be possible to close.
>>>> 
>>>> -- Magnus
>>>> 
>>>> On Mon, 20 Apr 2009, Frederick Hirsch wrote:
>>>> 
>>>>> We have a few  open issues related to elliptic curve. Please review and
>>>>> indicate if any can be closed, or what actions might be needed to close
>>>>> them.
>>>>> 
>>>>> ISSUE-92
>>>>> Include the \"implicitCA\" option for ECKeyValueType and separate
>>>>> ECDomainParameterType type
>>>>> Action needed?, volunteer for action?
>>>>> 
>>>>> ISSUE-93
>>>>> Missing a <Hash> element in the ds:ECParametersType type definition
>>>>> done with ECValidationDataType change. Propose to close.
>>>>> 
>>>>> ISSUE-103
>>>>> Shouldn't there be a REQUIRED curve in XMLENC as well as there is one in
>>>>> XMLDSIG
>>>>> Proposal needed? Volunteer for action?
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> regards, Frederick
>>>>> 
>>>>> Frederick Hirsch, Nokia
>>>>> Chair XML Security WG
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>
>
Received on Saturday, 25 April 2009 00:12:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:58 GMT