| 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
organisation, 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 together.
Use
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 evade 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, Mallory can also publish a public key (for which he knows the related private key) claiming it is
Alice's and so receive at least some of the secret messages meant for her. 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 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 cancelled 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 need 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.
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 work-group.
External links
|
