There are a number of concepts that are related, but they are different, and it
(can be) important to keep them straight.
Proof of possession -- how do you know that someone who gave you a cert has the
private key? This seems to be what the OP was writing about. Conceptually,
you give them something to encrypt with the private key and you decrypt it with
the public key.
Certificate verification -- does the signature on the certificate work, is it
within the validity period? Conceptually, basic math :)
Certificate validation -- Was the certificate not revoked? More complicated,
with OCSP and CRL's and such; note the phrasing of the previous sentence --
that's deliberate.
Path validation -- was the certificate signed by someone you trust? If you
can't answer that question, recurse -- was their certificate signed by someone
you trust, and so on. And were the signers doing things within the policies
allowed by their signer? (For example, you should reject a cert signed by
someone who doesn't have the "CA" bit enabled in their certificate.) And can
you verify the signer's certificate? Gets more complicated as the certificate
chains get longer. Conceptually, this is the more theoretical part of PKI and
also a major barrier to deployment. Note that
Certificate validation can also include application-oriented issues. For
example, in HTTP-over-SSL, the name in the server's certificate must "match"
the website you are connecting to. Looking at fields like the commonName part
of the subjectDistinguishedName, and the subjectAltName extension.
Hope this helps.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
