W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2009

Re ACTION-188: Provide additional arguments for (ECC) schema change

From: Magnus Nyström <magnus@rsa.com>
Date: Tue, 27 Jan 2009 20:22:44 +0100 (W. Europe Standard Time)
To: public-xmlsec@w3.org
Message-ID: <Pine.WNT.4.64.0901271832350.5484@W-JNISBETTEST-1.tablus.com>

This is to follow-up on my action ACTION-188 to present arguments for the 
design that I proposed in my email to the list:

http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0041.html

On the group's weekly call today, the argument raised by Brian against my 
proposal (as I understood it) was that it creates an extra layer, i.e. a 
wrapping element for the new type will be required. The extra layer means 
signatures will be larger (essentially the start and end tag of the 
wrapping element) and also there will be another node in the object tree 
when parsing EC public keys.

My arguments for the design change are:

- Reusability. By having a separate type for ECDomainParameters, it
   will be possible describe EC curves in other situations which do not
   directly include or require presence of an EC public key. I think it
   would be good to acknowledge that we may not know about such situations
   at this time, but by introducing such a type we will at least allow for
   them. The current design does not.

- Extensibility. By having a separate type it will be easier to leverage
   type substitution in case a third (like "implicitCA") or other
   alternative for describing EC curves arises. This would then not require
   changes to the ECKeyValue type, again something the current design does.

- Modularity (and consistent content model). By having an explicit EC
   domain parameters type as proposed, the design becomes more modular.
   Nowhere else in XMLDsig or XMLEnc is the method of having a complex type
   containing a choice between two elements of complex type in addition to
   other elements used. Instead, XMLDsig and XMLEnc quite consistently use
   the approach of defining "sub-types" even when there is only
   one usage of those "sub-types" in element definitions.

Obviously I respect the arguments raised against my proposal, but IMHO the 
advantages outweighs the disadvantages. I can't see that the minor size 
increase or complexity of an extra layer would be significant.

-- Magnus
Received on Tuesday, 27 January 2009 19:23:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:57 GMT