Public key certificate

From Wikipedia, the free encyclopedia

In cryptography, a public key certificate (or identity certificate) is an electronic document which incorporates 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 together.

1 Principles
2 Classes
3 Certificates and web site security
4 Certificate providers
5 See also
6 References

[edit] Principles

Certificates are useful for large-scale 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 secret messages to her, she needs only to publish her public key. Anyone who wishes to send her secure information can encrypt the information using Alice's public key, knowing that only Alice can decrypt the information with her corresponding private key. 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 another example, Alice and Bob need to share a message, but Alice may not be familiar with Bob's certificate authority. This scenario is common when Alice and Bob have different employers and their certificates were issued by their employer's CA. In this case, Bob's certificate may also include his CA's public key signed by a "higher level" CA₂, which might be recognized by Alice. This process leads to a hierarchy of certificates, and to even more complex trust relationships. Public key infrastructure mostly 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 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 embedded in the certificate (between an entity and a public key) changes or is discovered to be incorrect. This might occur if a person changes jobs or names. Although certificate revocation is usually rare, trusted certificates should always be checked for validity. This can be accomplished by comparing the certificate to a certificate revocation list (CRL), which 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. To be effective, CRLs must always be readily available to anyone who needs them, and they must be updated frequently. Online Certificate Status Protocol (OCSP) is another means for checking the validity of a certificate. OCSP uses a third-party server to parse the CRLs, and returns an answer to the client, rather than requiring the client itself to retrieve and interpret the CRLs.

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 digital signature of the certificate, produced by the CA's private key

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.

[edit] Classes

VeriSign introduced the concept of classes of digital certificates:

Class 1 for individuals, intended for email
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 authority
Class 4 for online business transactions between companies
Class 5 for private organizations or governmental security

[edit] Certificates and web site security

The most common use of certificates is for https web sites. A Web browser validates that an SSL (Transport Layer Security) Web server is authentic, so that the user can feel secure that their interaction with the Web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider with a certificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, and company information. The certificate provider signs the request, thus producing a public certificate. This public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believed that the provider issued a certificate to the owner of the web site. Before issuing a certificate, the certificate provider will request the contact email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is operated by someone in contact with the person that registered the Domain name.

As an example, when a user connects to https://www.example.com/ with their browser, if the browser gives no certificate warning message, then the user can be sure that interacting with https://www.example.com/ is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted.

[edit] Certificate providers

A 2005 Netcraft survey determined that VeriSign and its acquisitions such as Thawte have a 53% share of the certificate authority market, followed by GeoTrust (25%), Comodo (12%), GoDaddy (4%) and Entrust (2%).^[1] GeoTrust was subsequently acquired by VeriSign.

An April 2007 market share report from Security Space determined that VeriSign and its acquisitions (including GeoTrust) have a 59.6% share of the certificate authority market, followed by Comodo (8.3%), GoDaddy (5.3%), DigiCert (2.1%), Entrust (1.3%) and Network Solutions (1.1%).

CAcert.org is a community-driven certificate authority that issues free public key certificates.