This text is based on a Wikipedia.org article relating to Digital Certificates
In cryptography, a public key certificate (or identity certificate) is
a certificate which uses a digital signature to bind together a public
key with an identity — information such as the name of a person
or an organization, their address, and so forth. The certificate can be
used to verify that a public key belongs to an individual.
In a typical public key infrastructure (PKI) scheme, the signature will
be of a certificate authority (CA). In a web of trust scheme, the signature
is of either the user (a self-signed certificate) or other users ("endorsements").
In either case, the signatures on a certificate are attestations by the
certificate signer that the identity information and the public key belong
Certificates can be used for the large-scale use of public-key cryptography.
Securely exchanging secret keys amongst users becomes impractical to the
point of effective impossibility for anything other than quite small networks.
Public key cryptography provides a way to avoid this problem. In principle,
if Alice wants others to be able to send her secret messages, she need
only publish her public key. Anyone possessing it can then send her secure
information. Unfortunately, David could publish a different public key
(for which he knows the related private key) claiming that it is Alice's
public key. In so doing, David could intercept and read at least some
of the messages meant for Alice. But if Alice builds her public key into
a certificate and has it digitally signed by a trusted third party (Trent),
anyone who trusts Trent can merely check the certificate to see whether
Trent thinks the embedded public key is Alice's. In typical Public-key
Infrastructures (PKIs), Trent will be a CA, who is trusted by all participants.
In a web of trust, Trent can be any user, and whether to trust that user's
attestation that a particular public key belongs to Alice will be up to
the person wishing to send a message to Alice.
In large-scale deployments, Alice may not be familiar with Bob's certificate
authority (perhaps they each have a different CA — if both use employer
CAs, different employers would produce this result), so Bob's certificate
may also include his CA's public key signed by a "higher level"
CA2, which might be recognized by Alice. This process leads in general
to a hierarchy of certificates, and to even more complex trust relationships.
Public key infrastructure refers, mostly, to the software that manages
certificates in a large-scale setting. In X.509 PKI systems, the hierarchy
of certificates is always a top-down tree, with a root certificate at
the top, representing a CA that is 'so central' to the scheme that it
does not need to be authenticated by some trusted third party.
A certificate may be revoked if it is discovered that its related private
key has been compromised, or if the relationship (between an entity and
a public key) embedded in the certificate is discovered to be incorrect
or has changed; this might occur, for example, if a person changes jobs
or names. A revocation will likely be a rare occurrence, but the possibility
means that when a certificate is trusted, the user should always check
its validity. This can be done by comparing it against a certificate revocation
list (CRL) — a list of revoked or canceled certificates. Ensuring
that such a list is up-to-date and accurate is a core function in a centralized
PKI, one which requires both staff and budget and one which is therefore
sometimes not properly done. To be effective, it must be readily available
to any who needs it whenever it is needed and must be updated frequently.
The other way to check a certificate validity is to query the certificate
authority using the Online Certificate Status Protocol (OCSP) to know
the status of a specific certificate.
Both of these methods appear to be on the verge of being supplanted by
XKMS. This new standard, however, is yet to see widespread implementation.
A certificate typically includes:
The public key being signed.
A name, which can refer to a person, a computer or an organization.
A validity period.
The location (URL) of a revocation center.
The most common certificate standard is the ITU-T X.509. X.509 is being
adapted to the Internet by the IETF PKIX working group. The Public-Key
Infrastructure X.509 group, or PKIX, is a working group of the Internet
Engineering Task Force dedicated to creating RFCs and other standards
documentation on issues related to public key infrastructure (PKI) based
on X.509 certificates. PKIX was established in Autumn 1995.
Verisign introduced the concept of three classes of digital certificates:
Class 1 for individuals, intended for email
- Class 1 Certificates get saved by Internet Browsers such as Internet
Explorer, Firefox, Netscape, etc. To get a Digital Certificate file
you must export the certificate to a .PFX file. .PFX files are in accordance
with the RSA PKCS #12 standard;
Class 2 for organizations, for which proof of identity is required;
Class 3 for servers and software signing, for which independent verification
and checking of identity and authority is done by the issuing certificate