World Library  
Flag as Inappropriate
Email this Article

Online Certificate Status Protocol

 

Online Certificate Status Protocol

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate.[1] It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI).[2] Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Contents

  • Comparison to CRLs 1
  • Basic PKI implementation 2
  • Protocol details 3
  • Privacy concerns 4
  • Criticisms 5
  • Browser support 6
  • See also 7
  • References 8
  • External links 9

Comparison to CRLs

  • Since an OCSP response contains less information than a typical certificate revocation list (CRL), it puts less burden on network and client resources.[3]
  • Since an OCSP response has less data to parse, the client-side libraries that handle it can be less complex than those that handle CRLs.[4]
  • OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so other parties may intercept this information.[1]

Basic PKI implementation

  1. Alice and Bob have public key certificates issued by Ivan, the Certificate Authority (CA).
  2. Alice wishes to perform a transaction with Bob and sends him her public key certificate.
  3. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Ivan.
  4. Ivan's OCSP responder reads the certificate serial number from Bob's request. The OCSP responder uses the certificate serial number to look up the revocation status of Alice's certificate. The OCSP responder looks in a CA database that Ivan maintains. In this scenario, Ivan's CA database is the only trusted location where a compromise to Alice's certificate would be recorded.
  5. Ivan's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.
  6. Bob cryptographically verifies Ivan's signed response. Bob has stored Ivan's public key sometime before this transaction. Bob uses Ivan's public key to verify Ivan's response.
  7. Bob completes the transaction with Alice.

Protocol details

An OCSP responder (a server typically run by the certificate issuer) may return a signed response signifying that the certificate specified in the request is 'good', 'revoked', or 'unknown'. If it cannot process the request, it may return an error code.

The OCSP request format supports additional extensions. This enables extensive customization to a particular PKI scheme.

OCSP can be vulnerable to replay attacks, where a signed, 'good' response is captured by a malicious intermediary and replayed to the client at a later date after the subject certificate may have been revoked. OCSP overcomes this by allowing a nonce to be included in the request that must be included in the corresponding response. However, since most OCSP responders and clients do not support or use the nonce extension and Certificate Authorities (CAs) issue responses with a validity period of multiple days, the replay attack is a major threat to validation systems.

OCSP can support more than one level of CA. OCSP requests may be chained between peer responders to query the issuing CA appropriate for the subject certificate, with responders validating each other's responses against the root CA using their own OCSP requests.

An OCSP responder may be queried for revocation information by delegated path validation (DPV) servers. OCSP does not, by itself, perform any DPV of supplied certificates.

The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question, and must include a certain extension that marks it as an OCSP signing authority (more precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})

Privacy concerns

OCSP checking creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software vendor) to confirm certificate validity. OCSP stapling is a way to verify validity without disclosing browsing behavior to the CA.[1]

Criticisms

OCSP-based revocation is not an effective technique to mitigate against the compromise of an HTTPS server's private key. An attacker who has compromised a server's private key typically needs to be in a Man-in-the-middle position on the network to abuse that private key and impersonate a server. An attacker in such a position is also typically in a position to interfere with the client's OCSP queries. Because most clients will silently ignore OCSP if the query times out, OCSP is not a reliable means of mitigating HTTPS server key compromise.[5]

The MustStaple TLS extension in a certificate can require that the certificate be verified by a stapled OCSP response, mitigating this problem.[3] OCSP also remains a valid defense against situations where the attacker is not a "man-in-the-middle" (code-signing or certificates issued in error).

Browser support

  • Internet Explorer starting with version 7 on Windows Vista (not XP) supports OCSP checking[6]
  • All versions of Mozilla Firefox support OCSP checking. Firefox 3 enables OCSP checking by default.[7]
  • Safari on Mac OS X supports OCSP checking. It is enabled by default as of Mac OS X 10.7 (Lion). Prior to that, it has to be manually activated in Keychain preferences.[8]
  • Versions of Opera from 8.0[9][10] to the current version support OCSP checking.
  • Google Chrome disabled OCSP checks by default in 2012, citing latency and privacy issues[11]

See also

References

  1. ^ a b c A., Jesin (June 12, 2014). "How To Configure OCSP Stapling on Apache and Nginx". Community Tutorials. Digital Ocean, Inc. Retrieved March 2, 2015. 
  2. ^ "OCSP Stapling". GlobalSign Support. GMO GlobalSign Inc. August 1, 2014. Retrieved March 2, 2015. 
  3. ^ a b Gibson, Steve. "Security Certificate Revocation Awareness: The case for “OCSP Must-Staple”". Gibson Research Corporation. Retrieved March 2, 2015. 
  4. ^ Keeler, David (July 29, 2013). "OCSP Stapling in Firefox". Mozilla Security Blog. Mozilla Foundation. Retrieved March 2, 2015. 
  5. ^ "No, Don't Enable Revocation Checking". 19 April 2014. Retrieved 24 April 2014. 
  6. ^ "Federal Desktop Core Configuration (FDCC) solution".  
  7. ^ "Mozilla Bug 110161 - Enable OCSP by Default".  
  8. ^ Wisniewski, Chester (26 March 2011). "Apple users left to defend themselves against certificate attacks".  
  9. ^ Pettersen, Yngve Nysæter (November 9, 2006). "Introducing Extended Validation Certificates".  
  10. ^ Pettersen, Yngve Nysæter (3 July 2008). "Rootstore newsletter".  
  11. ^ Langley, Adam (5 Feb 2012). "Revocation checking and Chrome's CRL". Archived from the original on 2012-02-12. Retrieved 2015-01-30. 

External links

  • Public Key Infrastructure: Operational Protocols at DMOZ
  • RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
  • RFC 4806, Online Certificate Status Protocol (OCSP) Extensions to IKEv2
  • RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
  • Processor.com April, 2009 article about Online Certificate Status Protocol
  • CertificateRevocationCheck, Check the OCSP status for a certificate
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.