LDAPWiki: Public Key Infrastructure

Overview#

Public Key Infrastructure (PKI) is a system of digital Certificates, Certificate Authorities, and other registration authorities that verify and authenticate the validity of each party involved in an online transaction.

Public Key Infrastructure is also called a trust hierarchy.

When we are talking about Public Key Infrastructure here, then we are talking about the standards of the IETF's PKIX working group. The work of this group is based on the X.500 series ISO standards and aim toward improving the interoperability.

Public Key Infrastructure Best Practices are to create a Certificate Policies as defined in Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

A Certificate Authority (CA) or the Registration Authority is a trusted third-party organization or company that issues digital certificates and signs them with their own Trust Anchor to prove the origin of the certificates. One of the roles of the Certificate Authority or the Registration Authority in this process is to guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be. There have been some Exploits where the Identity of the Requester was not properly vetted. TLS Pinning is a method to help offset this Exploit.

Certificate Validation #

Certificate Validation is a very important part of Public Key Infrastructure.

Every time before using a key or certificate the validity of a Certificate has to be checked . In case of stolen or outdated certificates, these certificates will be revoked. Meaning, that before you trust the authentication of a message from anybody using his certificate, you should perform Certificate Validation.

Risks of validation by CRL#

To allow caching of a CRL at the users location, every CRL contains informations of its period of validity. That means a CRL can be issued every 5 minutes and have a period of validity of somewhat like an hour. As one can imagine this caching is directly linked to the risk that a revoked certificate is used. The longer a client is allowed to use (cache) an old CRL, the higher is the risk of using a revoked certificate.

The way of distributing a CRL (via HTTP or LDAP) imposes the problem of network traffic. CRLs of large Trust Centers can reach big size (around 0,5 MB). Every client trusting a server of one of this large Trust Centers should download the complete CRL. This is not only a significant delay in accessing these websites for the user but also generates a very high network traffic. The solution to this maybe to allow caching of these CRLs for a longer time, but as mentioned before this imposes a higher risk of using revoked certificates.

Validation with Online Protocols#

To solve the problems of Certificate Validation in an efficient manner the PKIX working group of the IETF (The Internet Engineering Task Force) proposed a Online Certificate Status Protocol (OCSP) in June 1999 and finalized another flavor of Online Certificate Validation by releasing the Simple Certificate Validation Protocol (SCVP) in 2003.

These protocols allows a client to request informations regarding the validity of one or more certificates which will be answered (and digitally signed) by a so called responder.

This method to do certificate validation implicates two major improvements. The first and foremost is an efficient risk management as an online-responder is able to provide real-time status information to the user. The second improvement that this protocol lessens the network traffic significantly, as users do not receive a huge list, needing only a few entries but only get the information they need. To ensure a maximum compatibility with the various networks, HTTP is used to transport the request and the response between a client and the responder.

Most e-commerce systems developed a lot of interest in this technology. This is not only because these protocols provide real-time validation and therefore allow them to setup an effective risk management, but also because of billing issues. The request of an online validation is the only communication between the "seller" in an e-commerce system and the system provider that occurs for every transaction. Thus the number of validation requests can be the basis for billing per request. By using this kind of billing system, the seller of a product in an e-commerce system is billed and not the "buyer" (end-user) as it is the case by selling certificates.

OCSP related specifications and details#

Technical standards and specification of CRL, OCSP are part of a family of standards for the X.509 (defines a standard certificate format) Public Key Infrastructure (PKI) for the Internet.

Specifications of the IETF are published on the Internet (so called Request for Comments, RFC). RFCs are the result of long discussions between workgroup members about a well defined problem. These documents specify an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC 2560 (IETF specification for OCSP)

This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. An overview of the protocol is provided, functional requirements are specified, more detailed information of the protocol is provided and security issues with the protocol are covered in this RFC.

RFC 3280 (obsoletes RFC 2459, IETF specification for PKI)

This specification profiles the format and semantics of certificates and certificate revocation lists (CRL) for the Internet PKI. Procedures are described for processing of certification paths in the Internet environment, for identification and encoding of public key materials and digital signatures and encoding rules are provided for popular cryptographic algorithms and procedures.

Public Key Infrastructure Weaknesses #

More Information#

There might be more information for this subject on one of the following: