Concepts
We describe important concepts with regard to the PKIX standards. A Public Key Infrastructure does not only need an infrastructure to handle identities, it needs an infrastructure to handle privileges. The distinction between the two will become more evident in the following sections.
Certificate–using Systems and PKIs
At the heart of recent efforts to improve Internet security are a group of security protocols such as Secure Multipurpose Internet Mail Extensions (S/MIME), Transport Layer Security (TLS), and Internet Protocol Security (IPSec). All of these protocols rely on public–key cryptography to provide services such as confidentiality, data integrity, data origin authentication, and non-repudiation. The purpose of a PKI is to provide trusted and efficient key and public key certificate management, thus enabling the use of authentication, non-repudiation, and confidentiality.
Security services Essential services to ensure the security on the Internet are confidentiality, data integrity, data origin authentication and non–repudiation. These can be achieved with protocols like S/MIME, TLS and IPSec . The protocols need a PKI in order to function effectively. |
Users of public key-based systems must be confident that, any time they rely on a public key, the associated private key is owned by the subject with which they are communicating. (This applies whether an encryption or digital signature mechanism is used.) This confidence is obtained through the use of PKCs, which are data structures that bind public key values to subjects. The binding is achieved by having a trusted CA verify the subject's identity and digitally sign each PKC.
A PKC has a limited valid lifetime, which is indicated in its signed contents. Because a PKC's signature and timeliness can be independently checked by a certificate-using client, PKCs can be distributed via untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
PKCs are used in the process of validating signed data. Specifics vary according to which algorithm is used, but the general process works as follows:
 | There is no specific order in which the checks listed below must be made; implementors are free to implement them in the most efficient way for their systems. |
The recipient of signed data verifies that the claimed identity of the user is in accordance with the identity contained in the PKC;
The recipient validates that no PKC in the path is revoked (e.g., by retrieving a suitably-current Certificate Revocation List (CRL) or querying an on-line certificate status responder), and that all PKCs are within their validity periods at the time the data was signed;
The recipient verifies that the data are not claimed to have any values for which the PKC indicates that the signer is not authorized;
The recipient verifies that the data have not been altered since signing, by using the public key in the PKC.
If all of these checks pass, the recipient can accept that the data was signed by the purported signer. The process for keys used for encryption is similar.
| It is of course possible that the data was signed by someone very different from the signer, if for example the purported signer's private key was compromised. Security depends on all parts of the certificate-using system, including but not limited to: physical security of the place the computer resides; personnel security (i.e., the trustworthiness of the people who actually develop, install, run, and maintain the system); the security provided by the operating system on which the private key is used; and the security provided the CA. A failure in any one of these areas can cause the entire system security to fail. PKIX is limited in scope, however, and only directly addresses issues related to the operation of the PKI subsystem. For guidance in many of the other areas, see RFC 2527. |
Certificate–using Systems and PMIs
Many systems use the PKC to perform identity based access control decisions (i.e., the identity may be used to support identity-based access control decisions after the client proves that it has access to the private key that corresponds to the public key contained in the PKC). For many systems this is sufficient, but increasingly systems are beginning to find that rule-based, role-based, and rank- based access control is required. These forms of access control decisions require additional information that is normally not included in a PKC, because the lifetime of the information is much shorter than the lifetime of the public-private key pair. To support binding this information to a PKC the Attribute Certificate (AC) was defined in ANSI and later incorporated into ITU–T Recommendation X.509. The AC format allows any additional information to be bound to a PKC by including, in a digitally signed data structure, a reference back to one specific PKC or to multiple PKCs, useful when the subject has the same identity in multiple PKCs. Additionally, the AC can be constructed in such a way that it is only useful at one or more particular targets (e.g., web server, mail host).
Users of a PMI must be confident that the identity purporting to posess an attribute has the right to possess that attribute. This confidence may be obtained through the use of PKCs or it may be configured in the AC-using system. If PKCs are used the party making the access control decision can determine "if the AC issuer is trusted to issue ACs containing this attribute."