Re: ACTION-219: ECPointType

Thanks Brian.

I agree that defaulting to SHA-1 is not a good idea. Fewer choices and  
defaults is probably better. No reason to pull that over.

regards, Frederick

Frederick Hirsch
Nokia



On Feb 20, 2009, at 4:49 PM, ext Brian LaMacchia wrote:

> Done.  I've just checked in a new version of xmldsig- 
> core-11\Overview.htm with the following changes:
>
> 1) In Section 4.4.2.3 (ECKeyValue)
>
> a) Changed the example ECPublicKey/PublicKey element to be one  
> base64-encoded value (corresponding to the changed schema for  
> PublicKey).  Note that the current Base64 value is just a  
> placeholder and is not guaranteed to be a valid PublicKey.
>
> b) Changed the text for the description of ECPublicKey/PublicKey to  
> read as follows:
>
>  The PublicKey element contains a Base64 encoding of a binary  
> representation of the x and y
>  coordinates of the point.  Its value is computed as follows:
>
>  1) Convert the elliptic curve point (x,y) to an octet string as  
> specified in Section 2.3.3 of
>  [SEC1]. Support for Elliptic-Curve-Point-to-Octet-String conversion  
> without point compression is
>  REQUIRED.
>
>  2) Base64 encode the octet string resulting from the conversion in  
> Step 1.
>
> COMMENT: I chose to represent the "no mandated support for point  
> compression" requirement by simply stating that support for non- 
> point-compressed forms was REQUIRED, and kept the spec silent on any  
> other forms (so implementations can do that if they want but it's  
> not commented on by the spec.)
>
> c) Removed the editor's note that the text on conversion of ECPoint- 
> >CryptoBinary was missing.
>
> 2) In Section 4.4.2.3.1 (ECParameters), added list item 6 describing  
> the Hash element.  Text as follows:
>
>  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).
>
> COMMENT 2: In SEC1 and X9.62-2005, if the Hash element is not  
> present in the ASN.1 then it defaults to SHA-1.  I chose not to make  
> the same statement here in XMLDSIG v1.1 because I don't believe  
> SHA-1 is an appropriate default going forward.  Because other  
> specifications use a default of SHA-1, for us to use another default  
> algorithm here would probably add confusion, so my suggestion at  
> this time is that we not define a default hash algorithm if this  
> element is absent.
>
> Comments/corrections welcome.
>
>                                        --bal
>
> -----Original Message-----
> From: Thomas Roessler [mailto:tlr@w3.org]
> Sent: Friday, February 20, 2009 5:11 PM
> To: Brian LaMacchia
> Cc: XMLSec WG Public List
> Subject: ACTION-219: ECPointType
>
> I've updated the XML Schema (and spec) to define ECPointType as a
> restriction on ds:CryptoBinary.
>
> Brian, we still need the text that says how the EC parameters are
> actually turned into an octet-stream.
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
>

Received on Friday, 20 February 2009 22:22:14 UTC