Handling End Entity Key Compromises using OCSP Stapling

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 }