Public key certificatecryptography and computer security, a public key certificate is a block of bits containing, in a specified format, the public half of an asymmetric key algorithm key pair (the "public key"), together with identity information, such as a person's name / email address / title / phone number / etc, together with the digital signature of all the data of some person or entity. They are also called identity certificates.
In a typical 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 signature(s) on a certificate are attestations that the identity information and the public key belong together.
|Table of contents|
2 See also
3 External Links
Certificates (or some equivalent scheme) are required 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 (any number of 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 trusted 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 perforce 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 (and of course must be revoked to retain whatever security may remain in the system), if it is discovered that its related private key has been compromised, or if the relationship (between a person/entity and a public key) embedded in the certificate is discovered to be wrong (eg, the CA or endorser made a mistake) or has changed (eg, 'person' changes jobs or names or ...). This will be (all fervently trust) a rare occurrence, but the possibility means that when a certificate is used (ie, trusted), the user should always check it against a list of revoked or cancelled certificates (ie, a Certificate Revocation List) which should, of course, be not only up to date but accurate. Maintaining such a list correctly is a core function in a centralized PKI, one which requires both staff and budget and one which is therefore sometimes not properly done. It must be readily, if not actually instantly, available to any who need it (eg, over the Internet) whenever it is needed (eg, 24/7/365) and must be updated very 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.