RE: Elliptic Curve Cryptography with PKIX

[Russ Housley <housley@xxxxxxxxxxxx>]

RFC 3280 does not provide as much guidance as I would like.  Section 
4.1.2.7 says the following about the  Subject Public Key Info field:

   This field is used to carry the public key and identify the algorithm
   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
   algorithm is identified using the AlgorithmIdentifier structure
   specified in section 4.1.1.2.  The object identifiers for the
   supported algorithms and the methods for encoding the public key
   materials (public key and parameters) are specified in [PKIXALGS].

Section 4.1.1.2 includes these words:

   The algorithm identifier is used to identify a cryptographic
   algorithm.  The OBJECT IDENTIFIER component identifies the algorithm
   (such as DSA with SHA-1).  The contents of the optional parameters
   field will vary according to the algorithm identified.

It does not really provide much guidance to developers of AlgorithmIdentifiers.

I characterize the X9.62 approach as using the OBJECT IDENTIFIER to 
name a class of elliptic curve algorithms, and then using a portion 
of the parameters to list the members of that class that are 
acceptable for the subject public key.

I am very interested to know how this fits with real implementations.

My suspicion is that implementation that support key agreement are 
used to looking into the parameter to determine if the public key is 
a member of the same group.  This is needed for static-static 
Diffie-Hellman (in discrete log or elliptic curve).  This is also 
needed for MQV (and KEA, if anyone cares anymore).

My suspicion is that digital signature validation does not anticipate 
constraints in the public key algorithm parameters.  An underlying 
crypto routine may need the parameters, but the signature is not 
going to fail because of a constraint in the parameters, which could 
happen in this proposed syntax.

I would greatly appreciate some insight from implementors.

Russ