Re: ACTION-219: ECPointType

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:

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

-- Magnus

On Fri, 20 Feb 2009, Frederick Hirsch wrote:

>> <Hash Algorithm="http://...">
>>       <Seed>asdfasdf</Seed>
> </Hash>
>
> seems much clearer than
>> <Seed Algorithm="http://...">asdfasdf</Seed>
>
>
> So I'd argue against the second choice.
>
> Regarding the Hash element, it seems reasonable, but would it introduce any 
> confusion to those familiar with the ASN.1 and looking for similarity? I'd 
> suggest not if we have the appropriate text in the document.
>
> Presumably there are no compelling reasons for keeping the two separate?
>
> Should we make this change now so that review reflects where we expect to end 
> up?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Feb 20, 2009, at 5:16 PM, ext Brian LaMacchia wrote:
>
>> I'd be OK with either of these alternatives; the current design follows the 
>> layout in X9.62-2005 and draft 1.7 of SEC-1.  Earlier versions of those 
>> specs had the seed but not the hash algorithm identifier, so I suspect the 
>> hash was put at the end of the ASN.1 structure so as not to break 
>> back-compat.  We don't have that problem here, so we're free to change the 
>> format as we see fit.
>>
>>                                       --bal
>> 
>> -----Original Message-----
>> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On 
>> Behalf Of Thomas Roessler
>> Sent: Friday, February 20, 2009 10:54 PM
>> To: Brian LaMacchia
>> Cc: XMLSec WG Public List
>> Subject: Re: ACTION-219: ECPointType
>> 
>> On 20 Feb 2009, at 22:49, Brian LaMacchia wrote:
>> 
>>> The Hash element is an optional element that specifies the hash
>>> algorithm used to generate the
>>> elliptic curve E and/or base point G verifiably at random.  If the
>>> Hash element is present then the
>>> optional Seed element in the Curve element must also be present.
>>> 
>>> COMMENT 1: I added the second sentence that if you specify the Hash
>>> element you must also specify the Seed element, because the Hash
>>> element doesn't make sense without the Seed element (they get used
>>> together to verify the curve was generated randomly)
>> 
>> It would seem more in line with the overall style of XML Signature to
>> put the hash algorithm into an attribute, and the Seed into a child of
>> Hash.  Having the two of them as siblings makes some sense when there
>> is a default hash algorithm specified.
>> 
>> So, I'd suggest something like this:
>>
>>  <Hash Algorithm="http://...">
>>       <Seed>asdfasdf</Seed>
>>  </Hash>
>> 
>> ... instead of the current approach.
>> 
>> Does this make sense, or am I missing something?
>> 
>> Or would something like...
>>
>>  <Seed Algorithm="http://...">asdfasdf</Seed>
>> 
>> make more sense?
>> 
>> 
>> 
>> 
>
>
>

Received on Monday, 23 February 2009 10:16:25 UTC