This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Online Certificate Status Protocol
Online Certificate Status Protocol

Version management

Difference between version and

At line 1 added 39 lines
!!! Overview
[{$pagename}] or [OCSP] is a [HTTP] [protocol] that allows a [Relying Party] to submit a certificate status request to an [OCSP Responder]
[{$pagename}] returns a definitive, [Digitally Signed] [response] indicating the [certificate] status. The amount of data retrieved per request is constant regardless of the number of [Revoked Certificates] in the [Certificate Authority].
Many [OCSP Responder]s get their data from published [CRLs] and are therefore reliant on the publishing frequency of the CA.
is used by browser software to query a [Certificate Authority] dynamically checking [Certificate Revocation] when performing [Certificate Validation]
The query request contains the serial number of the [Certificate] being checked as well hashes of the issuer name and [Public Key]. The request is sent to a [{$pagename}] server operated by the [Certificate Authority]. The response will either indicate that the certificate is:
* valid,
* revoked
* unknown
When using [{$pagename}], the final check for a certificate’s validity is to verify that the [Certificate Authority]’s [{$pagename}] server reports back that the certificate is ‘valid’.
! 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 [{$pagename}] ([OCSP]) in June 1999 and finalized another flavor of Online Certificate Validation by releasing the [Server-Based 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.
The [{$pagename}] 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 (as they do when using [Certificate Revocation List]s, 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.
!! Drawbacks with [{$pagename}]
The paper Towards Short-Lived Certificates[1] identifies following four drawbacks in [{$pagename}].
* [OCSP] validation increases client side [latency] because verifying a [certificate] is a blocking operation, requiring a round trip to the [OCSP responder] to retrieve the revocation status (if no valid response found in cache). A previous study indicates that 91.7% of OCSP lookups are costly, taking more than 100ms to complete, thereby delaying HTTPS session setup.
* [OCSP] may provide real-time responses to revocation queries, however it is unclear whether the responses actually contains updated revocation information. Some OCSP responders may rely on cached CRLs on their backend. It was observed that DigiNotar’s OCSP responder was returning good responses well after they were attacked.
* Similar to [CRLs], there are also multiple ways that an [OCSP] validation can be defeated, including traffic filtering or forging a bogus response by a network attacker. Most importantly, revocation checks in browsers fail open. When they cannot verify a certificate through OCSP, most browser do not alert the user or change their UI, some do not even check the revocation status at all. We note that failing open is necessary since there are legitimate situations in which the browser cannot reach the OCSP responder.
* [OCSP] also introduces a privacy risk: OCSP responders know which certificates are being verified by end users and thereby responders can, in principle, track which sites the user is visiting. OCSP stapling is intended to mitigate this privacy risk, but is not often used. [OCSP Stapling] is intended to mitigate this privacy risk, but is not often used.
Google has disabled [OCSP] in Chrome and instead uses [CRLSets] which uses its existing software update mechanism to maintain a list of revoked certificates.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Towards Short-Lived Certificates|http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf|target='_blank'] - based on information obtained 2016-05-11
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop