Re: ACTION-200: Detailing differences in ECC scheme proposals

This is in response to ACTION-200 that I got during this week's call, to 
show the differences in the two proposals we have for how to express EC 
public keys and curves.

I'd like to start by pointing out that this is not primarily about 
expertise in ECC but rather about alternatives in designing XML schema 
that supports ECC. So no deep ECC expertise required to weigh in here...

Essentially, what is to be expressed in XML schema is an ECC public
key as well as the curve the key belongs to.

The current design is:

<complexType name="ECKeyValueType">
   <sequence>
     <choice>
       <element name="ECParameters" type="dsig11:ECParametersType"/>
       <element name="NamedCurve" type="dsig11:NamedCurveType"/>
     </choice>
     <element name="PublicKey" type="dsig11:ECPointType"/>
   </sequence>
</complexType>

My proposed alternative design is:

<complexType name="ECKeyValueType">
   <sequence>
     <element ref="dsig11:ECDomain"/>
     <element name="PublicKey" type="dsig11:ECPointType"/>
   </sequence>
</complexType>

<element name="ECDomain" type="dsig11:ECDomainType"/>
<complexType name="ECDomainType">
   <sequence>
     <choice>
       <element name="SpecifiedDomain" type="ECParametersType"/>
       <element name="NamedCurve" type="dsig11:NamedCurveType"/>
     </choice>
   </sequence>
</complexType>

I.e. in a sample instance using the <NamedCurve> alternative, one
would in the current design have (namespaces omitted, and I am also
not sure if this is the right way to express OIDs as URIs, but that's
besides the [current] point):

<ECKeyValue>
   <NamedCurve>oid://1.2.840.10045.3.1.7</NamedCurve>
   <PublicKey> ... </PublicKey>
</ECKeyValue>

and in the alternative proposal:

<ECKeyValue>
   <ECDomain>
     <NamedCurve>oid://1.2.840.10045.3.1.7</NamedCurve>
   </ECDomain
   <PublicKey> ... </PublicKey>
</ECKeyValue>

The reason for the alternative design is as outlined in

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

:
- Reusability. By having a separate type for ECDomain, it
   will be possible describe EC curves in 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 (AFAICT) 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.

As for an example of reuse - something I was also asked to provide - 
consider a situation where two parties engage in a Elliptic-Curve 
Diffie-Hellman handshake. They would then first agree on the curve to use 
after which they will exchange public keys. If curve definition had its 
own type as in the alternative proposal then XML protocol designers could 
just reuse the ECDomainType type from XMLDsig/XMLEnc. If not, they would 
have to define their own.(*)

-- Magnus
-- 
(*) Actually, this example also suggests that an optimization can (or 
should, even) be done to both proposals, namely to have the choice as 
optional, i.e.:

<complexType name="ECKeyValueType">
   <sequence>
     <choice minOccurs="0">
       <element name="ECParameters" type="dsig11:ECParametersType"/>
       <element name="NamedCurve" type="dsig11:NamedCurveType"/>
     </choice>
     <element name="PublicKey" type="dsig11:ECPointType"/>
   </sequence>
</complexType>

or in the alternative design:

<complexType name="ECKeyValueType">
   <sequence>
     <element ref="dsig11:ECDomain" minOccurs="0"/>
     <element name="PublicKey" type="dsig11:ECPointType"/>
   </sequence>
</complexType>

This would be for the case when the EC domain/curve is known by other 
means and would also save space in those cases.
--

Received on Friday, 6 February 2009 13:04:51 UTC