Online Certificate Status Protocol
The Online Certificate Status Protocol ( OCSP ) is a network protocol that it clients allows the status of X.509 - certificates in a validation service query. It is described in RFC 6960 and is an Internet standard . This is required for checking digital signatures, for authentication in communication protocols (e.g. with SSL ) or for sending encrypted e-mails to check whether the certificates used to check the signature, to identify the communication partner or used for encryption, blocked and thus already invalid before the end of their regular validity period.
functionality
Using OCSP, the status of a certificate can be queried by requesting a server (a so-called OCSP responder). This OCSP responder is usually operated by the issuer of the certificate and returns "good" (ie the certificate is not revoked), "revoked" (certificate is revoked) or "unknown" (the status could not be determined, for example) because the issuer of the certificate is not known to the responder). Furthermore, there is the possibility that the OCSP responder issues so-called positive information (“certificate is authentic and valid”). A hash value of the certificate is given to the answer if the certificate actually exists. The OCSP standard RFC 2560 does not provide for positive information to be issued, so that its correct evaluation requires the OCSP clients to behave differently from the standard. In Germany, the issue of positive information provided for is qualified certificates of signature law demanded.
Regular answers (OCSP Response) are always digitally signed by the OCSP responder and can therefore be checked by the client for authenticity and falsification. Answers that represent error situations are not signed. The request (OCSP request) can be signed, but does not have to be; in practice, OCSP requests are rarely signed.
OCSP also allows the validity of several certificates to be queried in one request; the responder then provides a list with the respective certificate status in its response.
If an OCSP responder works on a current database (e.g. a replication of the certification authority's database), it always indicates the current revocation status of the certificate. For the validity of an electronic signature , however, the status of the certificate at the time of the check (and the OCSP query) may not be relevant, but the status at the (past) time of the signature (this applies e.g. to electronic signatures after German Signature Act ). For this reason, the OCSP responses for a revoked certificate must also indicate the revocation time so that it can be determined whether this certificate was still valid at a certain point in time. However, if the certification authority allows temporary blocks (suspensions), a positive OCSP response (“good”) does not indicate whether this certificate has been suspended in the meantime. However, this is not generally seen as a disadvantage of OCSP, but rather the suspension of signature certificates is viewed as problematic for electronic signatures. For this reason, such a suspension is not permitted for qualified certificates in Germany . In contrast to OCSP, the server-based Certificate Validation Protocol supports querying the certificate status at a previous point in time.
OCSP does not have its own transport protocol; http or https are usually used for transport .
distribution
OCSP is now supported by many standard programs and operating systems (e.g. Microsoft Windows Vista , Adobe Acrobat , Mozilla Firefox , Mozilla Thunderbird , Lotus Notes version 8, Opera from version 8). Some programs, especially older ones, only support certificate revocation lists (CRLs) for checking the certificate status.
In order to meet the requirements of the Signature Act for an up-to-date information service, all issuers of qualified certificates in Germany operate an OCSP responder.
Advantages and disadvantages
advantages
In contrast to revocation lists, which are only created at certain intervals and are therefore not always up-to-date, OCSP responders can provide revocation information that is accurate to the second, provided they use an up-to-date database (e.g. the CA database).
In addition, in contrast to revocation lists, OCSP makes it possible to distinguish non-revoked certificates from forged certificates - if the OCSP responder is configured in such a way that it only provides the answer "good" for certificates that actually exist (positive information). This becomes particularly important if the algorithms and key lengths used by the certification authority (CA) to sign the certificates become insecure over time and forgeries are possible. However, the standard stipulates that an OCSP responder delivers the answer “good” even if the certificate is not listed in a revocation list; in this case the certificate could not have been issued at all, i.e. H. be fake.
disadvantage
Like revocation lists, OCSP only provides information on the revocation status of certificates, but does not check the mathematical correctness of the signatures of the certificates, their period of validity or any usage restrictions specified in the certificate. In addition, the client must first determine a certification chain. In order to outsource these tasks to the information service, SCVP was developed.
The topicality of OCSP responses also depends on the database used. In some implementations, the OCSP responder is based on a revocation list and therefore does not provide any revocation information that is more up-to-date than this.
The problem is that many client implementations consider a certificate to be valid even if they receive the “tryLater” error response. Since error responses are not signed, an attacker can use forged “tryLater” responses to circumvent the OCSP check.
The original OCSP implementation can lead to considerable costs for the certification authorities, since they have to provide each client with real-time responses for a specific certificate. For example, if a website with a high traffic volume is issued a certificate, then the certification authority's servers are likely to be hit by a large number of OCSP queries that inquire about the validity of the certificate.
Privacy concerns
The use of OCSP raises questions regarding the protection of privacy because it requires the client to contact a third party in addition to the actual communication destination in order to check the validity of the certificate. One possibility to solve this problem is to use OCSP stapling . B. the browser behavior is not revealed.
See also
Norms and standards
The following is the development path for the current Request for Comments (RFC):
- RFC 2560 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP [June 1999, obsolete]
- Addition RFC 6277 - Online Certificate Status Protocol Algorithm Agility [June 2011, outdated]
- RFC 6960 - Current Version [June 2013, replaces RFC 2560 and RFC 6277]
Individual evidence
- ↑ Yngve Pettersen Nysæter: Introducing Extended Validation Certificates . Opera software . November 9, 2006. Archived from the original on February 10, 2010. Info: The archive link was automatically inserted and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved January 8, 2010.
- ↑ Yngve Pettersen Nysæter: Roots gates newsletter . Opera software . July 3, 2008. Archived from the original on November 18, 2008. Retrieved January 8, 2010.
- ↑ Moxie Marlinspike: Defeating OCSP (PDF; 64 kB) Retrieved January 27, 2011.
