PKI Entities

A PKI is the service framework needed to support large-scale public keybased technologies. The PKI is a set of all the technical, organizational, and legal components needed to establish a system that enables large-scale use of public key cryptography to provide authenticity, confidentiality, integrity, and nonrepudiation services.

Two very important terms need to be defined when talking about a PKI:

Note

Certificates are not secret information and do not need to be encrypted in any way. The idea is not to hide anything but to ensure the authenticity and integrity of the information contained in the certificate.

Another term that is often used with a PKI is certificate revocation list (CRL). The CRL is a list of certificates that should not be trusted anymore. Examples of when a certificate is added to the CRL ("revoked") include exposure or loss of the private key. A PKI user who receives a certificate should verify the CRL to ensure that the received certificate is not on the list of revoked certificates.

Many vendors offer CA servers as a managed service or as an end-user product:

X.509v3 Certificates

X.509 is the ubiquitous and well-known standard that defines basic PKI data formats, such as certificate and CRL format, to enable basic interoperability. This format is already extensively used in the infrastructure of the Internet. X.509 is used for these applications:

Figure 25-5 shows an example certificate format, following X.509 Version 3 (X.509v3). The most important pieces of information contained in the certificate are these:

Figure 25-5. Sample X.509 Certificate Format

Other fields include these:

Self-Signed Certificates

In a PKI system, all public keys are distributed in a form of a certificate, including the certificate of the trusted introducer, the CA. The obvious question is: Who signs the certificate of the CA, if it is itself the signer of all other certificates? In reality, the CA also issues a certificate to itself, just to have a consistent format for distributing its public key. This process is how the end entities obtain the public key of the CAby obtaining its self-signed certificate. The signature of a self-signed certificate of the CA cannot be verified using the standard method (verification by using the public key of the signer) because that public key should actually be protected by the signature. Therefore, other methods (such as manual verification) are needed to ensure the authenticity of a CA certificate.

Sometimes end entities also sign their own certificates. This happens if that particular end entity is not a part of a PKI but uses a PKI-enabled application. For example, a web server could generate a private and public RSA key and sign its public key with its private key to create a self-signed certificate. This certificate could then be used in Secure HTTP (HTTPS), where the web server would present a self-signed certificate to the connecting web browser. However, how does the web browser verify the presented certificate, if it was not issued (signed) by a known CA for which the web browser has a locally available certificate? This web server certificate, therefore, cannot be accepted automatically, but needs to be verified using some other method (such as the manual, out-of-band verification that is also used in pre-PKI protocols).

Категории