- From: Brian LaMacchia <bal@exchange.microsoft.com>
- Date: Tue, 24 Feb 2009 02:51:27 -0800
- To: Thomas Roessler <tlr@w3.org>, Magnus Nyström <magnus@rsa.com>
- CC: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
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).
Received on Tuesday, 24 February 2009 10:52:11 UTC