Thanks for the info.  I think I understand now.  A plain old digital
signature will not have the cert info, but a PKCS7 container does.  I think
that is what I have, if I followed the example correctly.  Am I correct in
saying that a PKCS7 container contains a digital signature + certificate
information?

In the verification process, it only verifies that the certificate was
signed by a "trusted" CA.  But I would like to know who this trusted CA is.
The reason is, this...I have a piece of data that I want to sign.  I give
this piece of data along with my application to someone else.  When this
person runs the app, I want to verify that he is using the data that I gave
him.  So I want to make sure the data he uses is signed by me.  To do that,
I run the verification on the signed data (the PCKS7 container).  But the
certificate validation only tells me if it was signed by a trusted CA.  But
there is nothing to prevent this person from creating their own CA, making
it a trusted CA on their system, creating their own data file, and signing
it.  That's why I want to make sure the data was signed by a certificate
that was issued to me, and that the root CA is the well known, trusted CA
that I had sign my cert; not his own CA that he made "trusted" on his
system.

Ed

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Bernhard Froehlich
> Sent: Friday, March 04, 2005 12:31 AM
> To: openssl-users@openssl.org
> Subject: Re: Questions about cert verification
> 
> Edward Chan wrote:
> 
> > I've been trying to follow the examples in "Network Security with 
> > OpenSSL".  But I just don't get it.  I know, I'm an idiot.  Can 
> > somebody point me in the right direction with the 
> appropriate API's to 
> > use for doing the following:
> >
> > I have a digital signature that I want to verify.  As part of my 
> > verification, I want to
> >
> > 1. get the certificate information from the signature. I 
> want to know 
> > who created the signature (so I want to look at the cert 
> that was used 
> > to create the signature).  I also want to know the the root CA who 
> > signed this cert.
> >
> > 2. how do I get an X509* to these certs?
> >
> > 3. how do I verify that the root cert is that of a specific 
> CA.  For 
> > this, can I simply compare the public key in this root cert 
> with the 
> > public key that is known for the CA of interest.  Is that enough to 
> > determine identity of the root cert?  Nobody else can create a self 
> > signed cert with the same public key can they?
> >
> > Does this make any sense?  I'm not sure if I'm explaining myself 
> > correctly, so this may seem like jibberish.  If so, please let me 
> > know.  And thanks for any help you can give.
> >
> > Thanks,
> >
> > Ed
> >
> I'm giving this a try, but I'm not very sure of myself in 
> this area. If something sounds not plausible (or you know 
> that it's wrong) please correct me.
> 
> The "digital signature" in a technical sense (like it is used 
> in Chapter
> 8 of the O'Reilly book) consists of the encrypted checksum of 
> the data. 
> So it does not contain a certificate or even an ID of the key 
> used to generate it. You have to know the key in advance 
> before you can check the signature.
> Applications which digitally sign data (like S/MIME) usually 
> transfer additional information to specify the used key and 
> its certificates. In the case of S/MIME a PKCS#7 container is 
> used to this effect.
> So you cannot verify a "naked" signature without knowing the 
> public key. 
> On the other hand, if you have a PKCS#7 container you can use 
> the approach described in the book's Chapter 10 
> (PKCS7_verify) or use other
> PKCS7 APIs to extract public key and certificate from the container.
> To be sure a certificate is issued by a specific CA you 
> should use this CA's certificate as the only trusted CA in 
> the verification process. If you don't trust the CA for 
> issuing Sub-CA-certs you can additionally check the length of 
> the certificat chain. This should take care of the issue in 
> the most appropriate way.
> Comparing public keys may also work, but why to repeat the 
> job that has already be done by OpenSSL in the verification process?
> 
> Hope it helps
> Ted
> ;)
> 
> --
> PGP Public Key Information
> Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
> Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26
> 
> 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to