RE: ACTION-219: ECPointType

This is fine with me. I also feel that the group probably needs a little 
more time here - and as Brian points out, my schema was more of an outline 
than a precise proposal.

-- Magnus

On Tue, 24 Feb 2009, Brian LaMacchia wrote:

> Continuing my curmudgeonly mood this morning :-), while I think a restructuring like Magnus has proposed has merit, I don't see a reason to rush this change into the FPWD.  Better that we think through the structure we want & associated schema first.  For example, I think we will need default "false" values on the Booleans.  Also, does it really make sense to validate the curve was generated randomly but not the base point (curveRandom=true, pointRandom=false)?  And I'm not sure whether it's better for HashAlgorithm to be an attribute or element.
>
> So, I think we should take this as a work item but not aim to change the FPWD at the last moment.
>
> 						--bal
>
> -----Original Message-----
> From: Thomas Roessler [mailto:tlr@w3.org]
> Sent: Monday, February 23, 2009 12:32 PM
> To: Magnus Nyström
> Cc: Frederick Hirsch; Brian LaMacchia; XMLSec WG Public List
> Subject: Re: ACTION-219: ECPointType
>
> On 23 Feb 2009, at 11:15, Magnus Nyström wrote:
>
>> I think Thomas suggestion to have a renewed look at the design is a
>> good one, but I think it would be a little strange to have the seed
>> as a child of a hash element, since the seed is not really part of
>> the hash.
>
>> IF we are to change Brian's latest draft (but note that I'd be OK
>> with it as is), then an alternative suggestion could be something
>> like:
>
> Looks better to me than the previous one.  I'd be happy to merge this
> into the FPWD if there are no objections.
>
> Any comments?
>
>> <complexType name="ECParametersType">
>>      <sequence>
>>        <element name="FieldID" type="dsig11:FieldIDType"/>
>>        <element name="Curve" type="dsig11:CurveType"/>
>>        <element name="Base" type="dsig11:ECPointType"/>
>>        <element name="Order" type="ds:CryptoBinary"/>
>>        <element name="CoFactor" type="integer" minOccurs="0"/>
>>        <element name="ECValidationData"
>>                 type="dsig11:ECValidationDataType" minOccurs="0"/>
>>      </sequence>
>>    </complexType>
>>
>> <complexType name="ECValidationDataType">
>>  <sequence>
>>    <element name="seed" type="ds:CryptoBinary"/>
>>  </sequence>
>>  <attribute name="hashAlgorithm" type="anyURI" use="required" [?] />
>>  <attribute name="curveRandom" type="boolean"/>
>>  <attribute name="pointRandom" type="boolean"/>
>> </complexType>
>>
>> ... and remove the "seed" element from the curve type:
>>
>> <complexType name="CurveType">
>>  <sequence>
>>    <element name="A" type="ds:CryptoBinary"/>
>>    <element name="B" type="ds:CryptoBinary"/>
>>  </sequence>
>> </complexType>
>>
>> The advantage of the above design would be that you gather all EC
>> validation data in a type of its own, and you will also be able to
>> express whether the verifiability is for the curve (curveRandom =
>> true), the point (pointRandom = true), both (both = true) or none
>> (that's when the ECValidationData element is not present at all).
>
>
>
>
>