• Choose a category
• All
• Classic-Fiction

A local registration authority (LRA) takes the process one step further. It can be used to identify or establish the identity of an individual for certificate issuance. If the user in Seattle needs a new certificate, it would be impractical to fly back to Washington, D.C., to get another one. An LRA can be used to verify and certify the identity of the individual on behalf of the CA. The LRA can then forward authentication documents to the CA to issue the certificate.

The primary difference between an RA and LRA is that the latter can be used to identify or establish the identity of an individual.

FIGURE 7.11 An RA offloading work from a CA

Figure 7.12 shows this process occurring between an LRA and a CA. The LRA would involve an individual or process to verify the identity of the person needing a certificate. The arrows in Figure 7.12 show the path from the user who requested the certificate (via the LRA) to the CA that issues the certificate; the arrows indicate the path from the CA sending the new certificate back to the user.

FIGURE 7.12 The LRA verifying identity for the CA

The LRA involves the physical identification of the person requesting a certificate.

The next sections provide more detail about certificates and their uses, including validating users, systems, and devices. A certificate also has certain characteristics that will be briefly explained.

Implementing Certificates

Certificates, as you may recall, provide the primary method of identifying that a given user is valid. Certificates can also be used to store authorization information. Another important factor is verifying or certifying that a system is using the correct software and processes to communicate. What good would a certificate be to help ensure authenticity if the system uses an older cryptography system that has a security problem?

The next few sections describe the X.509 certificate structure and some of the more common usages of certification.

X.509

The most popular certificate used is the X.509 version 3. X.509 is a standard certificate format supported by the International Telecommunications Union (ITU) and many other standards organizations. Adopting a standard certificate format is important for systems to be assured interoperability in a certificate-oriented environment.

The format and contents of a sample certificate are shown in Figure 7.13.

FIGURE 7.13 A certificate illustrating some of the information stored

Notice that the certificate contains identifiers of two different algorithms used in the process. In this case, the signature algorithm is Md2RSA, and the digital signature algorithm is sha1. This certificate also has a unique serial number issued by the CA.

An X.509 certificate has more fields than are illustrated; this example is intended only to give you an overview of what a certificate looks like.

Always remember that the purpose of the certificate is to basically bind the public key to the user’s identity. When authenticating, certificates can be used to authenticate only the client (single sided) or both parties (dual sided), the client and server. Aside from the Security+ objectives, no one uses the term dual-sided certificates.

Certificate Policies

Certificate policies define what certificates do. A CA can potentially issue a number of different types of certificates: say, one for e-mail, one for e-commerce, and one for financial transactions. The policy might indicate that it isn’t to be used for signing contracts or for purchasing equipment. Certificate policies affect how a certificate is issued and how it’s used. A CA would have policies regarding the interoperability or certification of another CA site; the process of requiring interoperability is called cross certification. The organizations using the certificates also have the right to decide which types of certificates are used and for what purposes. This is a voluntary process in that each organization