(Some of the information in this section could be old and out of date already).

The DSA certificate generation code has a few problems right now. The 'req' command works perfectly, it sends the parameters. The 'x509' command works for one level, and the 'ca' command does not work at all. In more detail:

The problem is that the ITEF standard for DSA specifies that for DSA certificates, where possible, the parameters will not be encoded into the certificate. If possible it will be encoded in the root of the certificate chain. For SSLeay, this means that when a DSA certificate is loaded, you also need to load the parent DSA certificate so that the DSA parameters can be propagated down. When a

call is made, the public key returned is cached in the X509 structure. If the actual certificate did not contain all the required parameters, they will continue to be missing until they are retried from a parent certificate.

EVP_PKEY_missing_parameters(EVP_PKEY *pkey) will return 1 if parameters are missing from a public key.

EVP_PKEY_copy_parameters(EVP_PKEY *to, EVP_PKEY *from) will copy the parameters between public/private keys.

Since the EVP_PKEY structure is used to hold both public and private keys, if you have the private key,

Can be used to fix the problem.

X509_get_pubkey_parameters(EVP_PKEY *pkey;STACK *chain) will search the X509 certificates in 'chain' and if missing parameters are found, will propagate them back into all the certificates below and into 'pkey' if it is present.

Now the problem of using these functions is that you still need to manually load the parent certificates. This is not a problem when you have the private key, but if you don't, X509_verify_cert(X509_STORE_CTX *ctx) can be used to verify a certificate, the process of validation will propagate the parameters.

The problem for the 'X509' and 'ca' programs is that when there is a 3 level certificate hierarchy, we are signing A with B. B needs to either propagate down the parameters from it's issuer, C, or have it's private key supply them. The 'ca' and 'x509' programs need to be modified to do this correctly.

When using DSA certificates, it is vital that the full certificate chain be available. Without it, none of the certificates can be verified.

These are funny beasties. Once the DSA certificate code is working, it should be simple enough to put these in. Their main problem is that a client could have hundreds of DH certificates to choose from when responding to a server.

At this point in time, if a client certificate is registered against an SSL structure, it is automatically returned if a client certificate is requested. The client certificate type information is ignored. If the 'get client certificate' callback is used instead, the information is available to the application but not in a nice way. The application needs to grovel around in the SSLv3 data structures. This needs to be cleaned up with either a few functions or a few macros.

There is currently still no bignum blinding.

back