A certificate authority (CA) is any entity or organization that issues certificates. The CA can be any trusted central administration willing to vouch for the identities of those to whom it issues certificates and their association with a given key. The functional word in this definition is trusted; the trust has to extend between the users in a particular transaction.
Any organization can choose to become a CA. A company, for example, might issue certificates to its employees, a college or university to its students, a retailer to its customers, an ISP to its users, or a government to its constituents. The post office, many banks and other financial institutions, and even hospitals are getting into this business. While on the surface, it may appear that issuing certificates is beyond the scope of its business, remember that all three currently operate with a relatively high degree of consumer confidence as far as protection and confidentiality of private information is concerned.
In order to prevent forged certificates, the CA’s public key must be trustworthy, or well known; a CA must either publicize its public key or provide a certificate from another CA attesting to the validity of its public key. The latter solution gives rise to hierarchies of CAs.
CA Hierarchies and Cross-Certification
When a CA sends Alice a certificate attesting to the binding between her identity and her public key, it will also send a certificate chain, which is the hierarchy of certificates verifying the CA’s public key. Alice can present this certificate chain to Bob whenever needed to demonstrate the legitimacy of her public key. Thus, CAs need to be able to issue certificates not only for end-users, but also for other CAs.
Consider some sample “certificates” in common use today, and the different uses they have because of the different inherent levels of trust in the issuer. Driver’s licenses, for example, are issued by a state to regulate motor vehicle operation, but are also accepted by other states for the same function (i.e., motor vehicle operation), and by still other agencies for other purposes (e.g., identification and proof of age). Credit cards, on the other hand, are almost worthless in most locations unless an authorization number can be obtained on a per transaction basis; on their own, they are rarely accepted as a form of identification (with the possible exception of those with photographs, which act as an independent verification) because of the lack of general trust in the distributing agencies. SCUBA certifications are accepted almost worldwide within the SCUBA community, but are rarely accepted elsewhere.
In the case of CAs, some sort of trust model must be defined by which CAs authenticate each other. The basic CA trust relationship model is a hierarchy that maps cleanly onto many traditional organizational structures and existing trust relationships. The so-called root CA is trusted by all CAs lower in the hierarchy; validating a certificate, then, means creating a certificate path back to the root. Different CAs will have different policies and procedures for certifying other CAs, just as CAs have different policies for verifying the identification of individual users (e.g., some CAs might issue a certificate based on a secure email request, while others might require an individual to present two other forms of identification). In general, a CA will be certified by another CA higher in the hierarchy (i.e., closer to the root) with the same or higher level of assurance.
In practice, the implied trust defined by this model means that there could be more than one certificate in a signed message. The receiver of the message verifies the sender’s certificate using the CA’s public key and verifies the message’s signature. There may be two or more certificates enclosed with the message, forming a hierarchical chain where one certificate authenticates the previous certificate. At the end of a certificate hierarchy is the top-level, or root, CA, which is trusted without a certificate from any other authority. The public key of the top-level CA must be independently known by, for example, being widely publicized (such as in the classified section of USA Today).
The hierarchical model also covers the case where Alice and Bob have different CAs within the same trust hierarchy. If their CAs do not share a common root CA, however, cross-certification must be performed. Cross-certification, by definition, means that the root CAs of two different trust hierarchies are disjointed; otherwise, they would share a root CA somewhere. In all likelihood, root CAs will develop bilateral trust relationships. Thus, a hybrid model for trust relationships will most likely be established.
An organization that becomes a CA must perform a number of services. The most obvious is to identify users and issue certificates, according to some certification practice statement (CPS). The certificate issuance process is roughly as follows: Alice generates a key pair and sends the public key to an appropriate CA. The CA checks Alice’s identification and takes any steps necessary to assure itself that the request is really coming from Alice. The CA sends Alice a certificate attesting to the binding between her identity and her public key.
The identification issue is very important and potentially quite thorny. Different CAs have different identification policies and will, therefore, be trusted differently by other CAs. Since the CA must check for proper identification, many organizations find it convenient to act as a CA for its own members and employees, and the organization itself acts as the trusted agent for another CA. Suppose, for example, that all employees of Hill Associates, Inc. (HAI) need to have certificates. In one scenario, all HAI employees could obtain individual certificates from the VeriSign, or other commercial, CA. Alternatively, HAI could adopt a set of certificate issuance policies and procedures acceptable to VeriSign (or other commercial CA), and then act as a CA for all of their employees; in this case, VeriSign has certified the HAI CA.
Different CAs issue certificates with varying levels of identification requirements. One CA might insist on seeing a driver’s license or passport, while another might want the certificate request form to be notarized, or include the fingerprints, voiceprints, or retinal scan of the requesting party. Each CA should publish its own identification requirements and standards so that other verifying CAs can attach the appropriate level of confidence in the certified name-key bindings. CAs with lower levels of identification requirements produce certificates with lower levels of assurance; CAs can be considered to be of high, medium, and low assurance, and the assurance level is often a way to select one CA over another.
In addition to policies governing issuance of certificates and identification of requesting parties, CAs must have operational procedures for renewing and revoking certificates. All certificates have an expiration date, usually one, two, or five years after issuance. The CA must be able to renew a certificate prior to expiration upon request of the user. Revocation is harder and more crucial; certificates could have to be revoked in case any information in the certificate changes (e.g., job function, authorization level, account number, etc.), the user violates some certificate usage policy, or the private key is lost or compromised. When a certificate is revoked, this information must be made available as soon and as widely as possible.
When certificates are revoked prior to their expiration period, they are added to a certificate revocation list (CRL). When Bob checks the certificate associated with a message sent by Alice, Bob should also check the CRL to be sure that Alice is not on it!
Another major problem is that of cross-certification. Suppose that Alice has a certificate issued by a CA that is “foreign” to Bob. The cross-certification issue is that somehow Alice and Bob must find a CA in common that will certify both certificates.
More and more commercial CAs are becoming available in North America, including AT&T, Canada Post Corp., Entrust, Verizon, U.S. Postal Service, and VeriSign.