Public key certificate

A public key certificate consists of the public portion of an asymmetric cryptographic key (the "public key"), together with identity information, such as a person's name, all of which is signed by a certificate authority[?] (CA). The CA essentially guarantees that the public key belongs to the named entity.

Certificates are required for the large-scale use of public-key cryptography, since anybody can create a public-private key pair. So in principle, if Alice is sending private information encrypted with Bob's public key, a malicious Eve can fool Alice into using Eve's own public key, and so get access to the information, since it knows the corresponding private key. But if Alice only trusts public keys which have been signed ("certified") by an authority, then this attack is prevented.

In large-scale deployments Alice may not be familiar with Bob's certificate authority (perhaps they each have a different company CA), so Bob's certificate may also include his CA's public key signed by a "higher level" CA₂, which is presumably recognized by Alice. This process leads in general to a hierarchy of certificates, and even to more complex graphs representing trust relations. Public key infrastructure refers to the software that manages certificates in a large-scale setting.

A certificate may be revoked, if it is discovered that the private key that it is related to has been exposed. This is a rare occurrence, but it means that when a certificate is used (=trusted), one needs to look up the revocation list which is often stored remotely.

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 for the Internet by the IETF PKIX[?] work-group.