Victor B. Wagner wrote: ...
--- /home/vitus/src/openssl-SNAP-20041105.orig/apps/req.c 2004-11-09 12:35:42.000000000 +0300
+++ apps/req.c 2004-11-15 14:24:36.000000000 +0300
@@ -167,9 +167,10 @@
...
else if (strcmp(*argv,"-new") == 0)
{
+ as=EVP_get_asymmetricbynid(NID_rsaEncryption);
+ if (!as) {
+ BIO_printf(bio_err,"RSA algorithm is not supported by this version of OpenSSL\n");
+ goto end;
+ }
+ pkey = EVP_PKEY_new();
newreq=1;
+
}
why ? in case I want to create a new cert request for a dsa key I don't need rsa support.
For compatibility with existing behavoir. "-new" creates only RSA keys. One should specify "-newkey" with algoritm specification to create other key. This is documented in the req(1) manual page.
the 'new' option doesn't specify a private key type. When no private key is specified (either via '-key' or '-newkey') the default key type RSA is used => the above check isn't really appropriate.
May be there is an error and we are trying to find RSA algorithm description before we've checked that existing private key is provided.
yep
...
Yes (if this algorithm doesn't accept V_ASN1_NULL as parameters), but if such an algorithm exists, than X509_ALGOR structure should be modified. We think that for now it can be left as is, because it works for existing algorithms, and for all ones we are planning to add.
I'm not sure that X509 standard allows parameters to be entirely omitted, not just a NULL sequence.
well the parameter field is optional, hence it should be allowed to omit it (but that shouldn't really be a problem)
...
+
+static int d2i_EC_X509_pub_key(EVP_PKEY *key, const unsigned char *buf, long length) {
+ /* Moved from d2i_PublicKey */
+ if (!o2i_ECPublicKey(&(key->pkey.eckey),
+ &buf, length))
the name d2i_EC_X509_pubkey isn't appropriate for this function, as it
Why you choose this as example? If d2i isnt appropriate here, it is not appropriate as name of EVP_ASYMMETRIC structure field at first.
;-) at higher levels it seems to a OpenSSL tradition to call encode (resp. decode) functions i2d_* (resp. d2i_*), but in this case this naming convention is misleading and wrong
Btw: wouldn't it be better (cleaner) to put these algorithm specific functions in the corresponding directory (i.e. crypto(rsa etc.)
I think it would be better to do along the way it is done for message
digests and ciphers - put these routines into appropriate named files
in the evp directory.
don't agree
Cheers, Nils ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
