!!! Overview
[{$pagename}] ([PKI]) is a system of digital [Certificates], [Certificate Authorities|Certificate Authority], and other [registration authorities|Registration Authority] that verify and authenticate the validity of each party involved in an online transaction. 

[{$pagename}] is also called a [trust] hierarchy.

When we are talking about [{$pagename}] here, then we are talking about the standards of the [IETF's PKIX working group|http://www.ietf.org/html.charters/pkix-charter.html]. The work of this group is based on the [X.500] series [ISO] standards and aim toward improving the interoperability.

[{$pagename}] [Best Practices] are to create a [Certificate Policy] 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|Certificate Pinning] is a method to help offset this [Exploit].

[{Image src='Public Key Infrastructure/PKI Infrastructure Overview.png'}]

!! [Certificate Validation]
[Certificate Validation] is a very important part of [{$pagename}].

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|http://www.ietf.org/rfc/rfc2560.txt?number=2560] 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.

RfC2560 (IETF specification for [OCSP|http://www.ietf.org/rfc/rfc2560.txt?number=2560])

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|http://www.ietf.org/rfc/rfc3280.txt?number=3208] (obsoletes [RFC 2459|http://www.ietf.org/rfc/rfc2459.txt?number=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:
[{ReferringPagesPlugin before='*' after='\n' }]