(801) Ultralight OCSP Improving Revocation Checking

Ultralight OCSP Slide Title 3 Recent Attacks On Certification Authorities 4 What was learned? 5 Can we fix revocation? 7 A suggested approach 8 Lightweight OCSP 14 Feedback 15 Contacts Table of Contents

Recent Attacks On Certification Authorities Comodo – Mar 2011 –Multiple RA breaches : mis-issuance of at least 9 certificates –Italian & Brazilian RAs were targeted StartCom – Jun 2011 –Breach of Server : no certificates mis-issued –DoS of services to StartCom customers result DigiNotar – Jul 2011 (didn't disclose until Aug 2011) –Major Breach : 500+ certs issued caused by poor security –CA now out of business Globalsign – Sept 2011 –Breach of Server : but no certificates were mis-issued DigiCert Malaysia (no relationship to US company) – Oct 2011 –Issues certificates with weak keys, lacking extensions to revoke them –Bad certs were re-purposed to sign malware –CA certificate was revoked KPN (Dutch CA related to DigiNotar) – Nov 2011 –Breach of Server : no certificates mis-issued –DoS of services to KPN customers result

What Was Learned? There are a couple of main issues with SSL/TLS infrastructure: –Revocation is not as reliable as it needs to be Black lists only for status checks do not enable validation of certs issued –The entire CA infrastructure is being held hostage by a few weak participants Proper validation of identities is being circumvented by poor implementation processes or inadequate audit routines

Can we fix Revocation Addressing one of the concerns raised, we wonder if its possible to adjust revocation concerns with a small set of criteria –Incremental adjustments to existing protocols –Improved scalability –Improved availability –Maintain privacy –Decreased size

Can we fix Revocation We sponsored well known experts to conduct research in this regards Participants in the research include: –DigiCert –Dartmouth –NYU Coalescing ideas around the discussions in industry groups –Validating proposals in various trust communities IGTF CAB Forum

One Current Approach Build upon the Lightweight OCSP Profile for High-Volume Environments defined in RFC 5019 –facilitate the distribution of OCSP responses over Content Distribution Networks (CDNs) –eventually over other similar alternative distribution channels, including through DNS and OCSP Stapling –we call this Ultralight OCSP

Ultralight OCSP The major changes from Lightweight OCSP for those implementing Ultralight OCSP would be as follows: –A new http-based OCSP Request URI specification requiring the addition of a profile identifier at the end of the OCSP URL for ultralight-capable systems –OCSP Requests that enable the use of HTTP GET over CDNs –Add certificate Fingerprints in OCSP Responses –Policy OID to indicate a client should hard-fail if the SSL/TLS Certificate cannot be verified with OCSP or any of the alternative revocation checking methods supported in the certificate and the browser

Ultralight OCSP A new http-based OCSP Request URI specification requiring the addition of a profile identifier at the end of the OCSP URL for ultralight-capable systems, e.g., – –with reference to Section 5 of RFC 5019, the client behavior for the transport profile says: OCSP clients MUST base64 encode the OCSPRequest structure and append it to the URI specified in the AIA extension –An example of this would be as follows: G9w0CBQQQ7sp6GTKpL2dAdeGaW267owQQqInESWQD0mGeB ArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbp%3D%3D;

Ultralight OCSP Predictable OCSP Requests that enable the use of HTTP GET over CDNs require predictability, therefore OCSP Requests –(a) SHALL use HTTP GET, –(b) SHALL NOT be signed, and –(c) SHALL NOT contain a nonce.

Ultralight OCSP This proposed new non-critical certificateFingerprint extension (CABF/PKIX OID TBD) would ensure that the CA has knowledge of the issuance of the Certificate whereas current OCSP responses (containing only serial number, issuerNameHash, and issuerKeyHash) do not provide proof of such knowledge

Ultralight OCSP This proposed CA / Browser Forum policy (CAB Forum Policy OID TBD) would send a strong signal to client software of the CA’s and Subscriber’s intent that any client software encountering the OID should hard-fail if the SSL/TLS Certificate cannot be verified with OCSP or any of the alternative revocation checking methods supported in the certificate and the browser. The Policy OID is not intended to interfere with the X.509 path validation algorithm requiring that policy OIDs represent the present certificate’s compliance with the asserted Certificate Policy

Ultralight OCSP We believe Ultralight OCSP with its described attributes would meet the demands of a reliable, available, scalable revocation solution Access via a simple profile identifier in the existing URI makes it easy to implement GET calls to a CDN provides scalability, availability, and potentially privacy depending on the relationship with the CDN Including a fingerprint in the response allows for whitelist status results rather than blacklist only Requiring hard-fail if status is not obtained facilitates the reliability of the system –the CA is making a commitment to always have a status available when it includes this policy in the cert

Feedback We invite feedback on these ideas by IGTF –See contact details on next slides At what point will IGTF move to more OCSP-like status checking rather than relying upon CRLs?

DigiCert Contacts Website: Scott Rea: (801) ,