>From: owner-openssl-us...@openssl.org On Behalf Of anu.engineer >Sent: Wednesday, 12 June, 2013 15:03
> I am reading thru the ca.c in the apps directory to understand how >to issue a certificate using OpenSSL and I came across this fragment >of code which I am struggling to understand. >Just before signing the certificate the code executes this fragment [indentation partially restored] >pktmp=X509_get_pubkey(ret); >if (EVP_PKEY_missing_parameters(pktmp) && > !EVP_PKEY_missing_parameters(pkey)) > EVP_PKEY_copy_parameters(pktmp,pkey); >EVP_PKEY_free(pktmp); >I looked up the man pages and the notes section talk about >The main purpose of the functions EVP_PKEY_missing_parameters() >and EVP_PKEY_copy_parameters() is to handle public keys in certificates >where the parameters are sometimes omitted from a public key >if they are inherited from the CA that signed it. >1) What parameters are we talking about here ? We just read the >Public Key from the CSR and we seem to copy some fields from the CA key >( in the code pkey) to pktmp key which is the key we read from the CSR. pktmp is a copy of the requester's publickey from the CSR, yes. The parameters for DSA are the group-defining prime p, subgroup order q, and subgroup generator g, and optionally some additional values that can be used to prove the parameters were generated "randomly" (i.e. not manipulated to force user keys into an possibly more breakable sub/group). As indicated, 3279/3280/5280 allow these to be omitted from PublicKeyInfo in child cert if they are the same as parent cert/key; this was apparently intended for cases like people in a business all using the same parameters for their keys and a corporate CA for their certs. AFAICS openssl won't *generate* a CSR like this, because its private keys are always complete, but some other software might. As no one seems to be using DSA certs on the public internet, there's no handy data to check this. The parameters for EC including ECDSA are in principle a prime integer for a GF(p) underlying field or a binary "basis" polynomial and its length for a GF(2^n) aka "binary" one, coefficients a and b of the curve equation, a base or generating point represented by two or sometimes one elements of the underlying field, the order of the result group and its "cofactor". In practice people don't generate their own EC parameters (which is hard) but instead use one of a few dozen standardized sets, which can be and usually are encoded in the cert as one OID, so there's no practical benefit to using inheritance and I doubt anyone does. There are no parameters for RSA; each key(pair) stands alone. But it doesn't look like this piece of code accomplishes anything. It would make some sense to inherit the parameters (if necessary) then check this key is consistent with the parameters (to the extent possible for a publickey), but it doesn't actually do that. Maybe it did in a past version but got neutered by some change -- and not noticed because in practice people rarely create or accept deliberately defective keys and CSRs. Even when a malefactor wants a fraudulent cert, it's a fraudulent binding to a valid key. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
