RE: ACTION-219: ECPointType

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 21:49:52 UTC