While CA provided certificate breaches are fairly uncommon, end entity key compromise occurs
much more often. Whether due to a server breach, stolen laptop, or a lost smart
card, these compromises occur daily. Fortunately, modern PKI systems are
designed with this in mind and CAs can revoke certificates and publish
revocation information in the form of CRLs, or provide online revocation status
using
OCSP.
OCSP is a an internet protocol based on X.509 internet public key infrastructure to check the validity status of a certificate in real time whenever browser wants to establish the https connectivity with the server. It is alternative to CRL (certification revocation list).
As CRL requires downloading of large payload and extremely time consuming when connected to the CRL issuer. Also, revocation information may not be up to date when it need to be used for pushing updates in mobile devices as applications using CRL does not require to be connected to the CRL issuer.
Advantages of using OCSP:
OCSP allows clients to query an OCSP server about the revocation status of individual certificates.
1. There is likelihood of certificates are always latest as user may obtain revocation of certificate information immediately.
2. OCSP certificates does not require much storage space, unlike CRL as certificate which is in consideration only need to be stored.
Disadvantages of using OCSP:
1. This requires application which uses the certificate to be online to know the revocation state.
OCSP specifics can be found in RFC 2560 - http://datatracker.ietf.org/doc/rfc2560/
An alternative to directly pushing revocation information as part of browser
updates is
OCSP Stapling, formerly known as the TLS
Certificate Status Request extension.
However, OCSP Stampling improves handshake between the browser and server by hosting digitally signed version with timestamp from the OCSP of CA response directly on the web server. This stapled OCSP response would be refreshed from the CA at pre-defined intervals set by the CA. The stapled OCSP response allows the webserver to include OCSP response within the initial SSL handshake without additional call to the CA server. The
web server rather than the client, queries the
certificate status from OCSP server in a regular interval.
OCSP Stapling specifics can be found in RFC 6066 - http://datatracker.ietf.org/doc/rfc6066/
Advantages of using OCSP Stapling:
1. Improves connection speed of the SSL handshake by combining two separate requests into one request. It reduces the time required to load an encrypted webpage.
2. Helps maintain the privacy of the the end client/user as no direct connection using end user IP address is made to the CRL for the OCSP request and CA server will only see OCSP requests from the web server, not end user requests.
3. When the user connect to the captive portal or hotspot to access the internet, client application cannot verity the OCSP check as there was no SSL/TLS handshake happened as access to the internet not granted yet due to pending authentication. However, using OCSP stapling takes care of SSL/TLS handshake.
Disadvantages of using OCSP Stapling:
1.Not all browser versions support OCSP Stapling.
Elements of an OCSP Request:
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING,
issuerKeyHash OCTET STRING,
serialNumber CertificateSerialNumber }
Elements of an OCSP Response:
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
