Online Certificate Status Protocol

The Online Certificate Status Protocol (OCSP ) is an Internet protocol that allows clients to query the status of X.509 certificates in a validation service. This is required for the verification of digital signatures in the authentication in communication protocols (eg, SSL) or for sending encrypted e -mails to check whether the certificates or to verify the signature, identifying the communication partner be used for encryption, locked and thus were invalid before the end of their regular validity period.

Operation

Using OCSP, the status of a certificate by request with a server ( a so-called OCSP Responder) to be queried. This OCSP responder is usually operated by the certificate authority and provides the answer " good" (that is, the certificate is not locked), " revoked " ( certificate is revoked ) or "unknown" ( the status could not be determined be, for example because the issuer of the certificate to the responder is not known). There is also the possibility that the OCSP responder so-called positive information (" certificate is authentic and valid" ) license. Here, the response is given a hash value of the certificate if the certificate actually exists. The provision of positive information, however, is not provided in the OCSP standard RFC 2560, so that their correct evaluation requires a different behavior from standard OCSP clients. In Germany the issue of positive information for qualified certificates is required by the Electronic Signature Act.

Regular responses (OCSP Response) are always digitally signed by the OCSP responder and can thus be checked by the client for their authenticity and genuineness. Responses that represent error situations are not signed. The request (OCSP Request) may be signed, but it need not be; in practice OCSP requests are rarely signed.

OCSP allows also to query the validity of multiple certificates in a request; the responder then provides in its response a list of the relevant certificate status.

If an OCSP responder on a current data base ( eg, a replication of the database of the certification body ) works, it always indicates the current revocation status of the certificate. However, for the validity of an electronic signature may or may not be the status of the certificate at the time of the test ( and the OCSP query ) relevant, but the status of the (past) time of signing (this applies for example to electronic signatures in accordance with the German Signature Act). Therefore, the OCSP responses must also specify the blocking time in a revoked certificate so that it can be determined whether this certificate at any given time was still valid. However, if the certification authority provides temporary closures ( suspensions ), you can not tell whether this certificate was suspended in the meantime a positive OCSP response ( "good "). However, this is generally not considered a disadvantage of OCSP, but rather viewed the suspension of signing certificates as problematic for electronic signatures. Therefore, such a suspension in Germany is not approved for qualified certificates. In contrast to the OCSP Server-based Certificate Validation Protocol supports the query of the status of certificates at a past date.

OCSP does not have a transport protocol, transport or https is usually used http.

Dissemination

OCSP is now available from many standard programs and operating systems (eg Microsoft Windows Vista, Adobe Acrobat, Mozilla Firefox, Mozilla Thunderbird, Lotus Notes version 8, Opera version 8) support. Some, especially older programs only support certificate revocation lists ( CRLs ) to check certificate status.

To meet the demand of the Signature Act according to a recent inquiry service, all exhibitors of qualified certificates in Germany operate an OCSP responder.

Pros and Cons

Benefits

Unlike CRLs, which are created only at certain intervals, and thus are not always up to date, can provide exact second lock information OCSP responder, unless they are using an actual database ( for example, the CA database ).

It also enables OCSP unlike revocation lists to distinguish not revoked certificates of forged certificates - if the OCSP responder is configured so that it the answer is " good" only delivers actually existing certificates (positive information ). This is especially important if the by the certification authority (CA ) to be possible to sign the certificates used algorithms and key lengths over time uncertain and fakes. However, the standard provides that an OCSP responder already then the answer is " good" delivers when the certificate is not listed in a blacklist; in this case, the certificate could not be issued also, that is, be faked.

Disadvantages

OCSP provides - such as check lists - only information on the revocation status of certificates, but does not validate the mathematical correctness of the signatures of the certificates, their validity or, if indicated in the certificate usage restrictions. In addition, the client must first identify a certification chain. To outsource these tasks to the information service, SCVP was developed.

Furthermore, the timeliness of OCSP responses depends on the data base used. In some implementations, the OCSP responder is based on a CRL, and therefore provides no recent revocation information than this.

The problem is that many client implementations also consider a certificate as valid if they get the error response " tryLater ". Since error responses are not signed, an attacker can nullify the OCSP checking by fake " tryLater " responses.