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.comwrote:
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
