Hi Dave, This is a very detailed and excellent answer, Thank you very much
Anu On Wed, Jun 12, 2013 at 6:59 PM, Dave Thompson <dthomp...@prinpay.com>wrote: > >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 >
