- From: Magnus Nyström <magnus@rsa.com>
- Date: Mon, 19 Jan 2009 00:03:50 -0500 (Eastern Standard Time)
- To: public-xmlsec@w3.org
(This is a long overdue review of Kelvin's analysis of issues with RFC
4050.)
Having looked at this in more detail, I agree with Kevin's analysis. The
important areas as I see it are the incompatibility with X9.62 wrt
ECPoints and the potential issues arising from the use of
nonNegativeInteger.
As for the current proposal, I have the following comments/questions:
- You don't want to include the "implicitCA" option for ECKeyValueType?
This allows for re-using an algorithm specified by a CA policy. (For
clarity and, perhaps future flexibility, I'd also suggest having a
separate ECDomainParameterType type as in X9.62 and then the
ECKeyValueType etc. would become:
<complexType name="ECKeyValueType">
<sequence>
<element ref="ds:ECDomainParameters"/>
<element name="PublicKey" type="ds:ECPointType"/>
</sequence>
</complexType>
<element name="ECDomainParameters" type="ds:ECDomainParametersType"/>
<complexType name="ECDomainParametersType">
<sequence>
<choice>
<element ref="ds:ExplicitECParams"/>
<element name="NamedCurve..."/>
<element name="ImplicitCA"/>
</choice>
</sequence>
</complexType>
<element name="ExplicitECParams" type="ds:ExplicitECParamsType"/>
<complexType name="ExplicitECParamsType">
<sequence ... -> same as current ECParametersType>
- I'm missing a <Hash> element in the ds:ECParametersType type definition.
In X9.62, this component is used to verifiably generate the curve. Do
you feel we do not need it, Kelvin?
- Also in the ECParameterType type definition, note that the <Order>
element may also be a large number and hence the use of the
"integer" type may again be problematic.
- For the PrimeFieldParameterType, note that primes will also be large
(larger than 18 decimal digits).
- The reference for conversion of an EC point to an Octet String would
perhaps better be to Appendix A.5.7 ("Point to Octet String").
Best,
-- Magnus
Received on Monday, 19 January 2009 05:04:27 UTC