Public key certificate

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. 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 well known it does not need to be authenticated.

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 Certificate Revocation List which is often stored remotely, and updated frequently.

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.

Referenced By