A better approach to the problem is to fix OCSP. This is the proposal I made to PKIX based on the problem analysis Adam gave.
I am not at all keen on just abandoning OCSP. But I guess I could live with a situation where the only OCSP that was going to be checked was stapled OCSP with the relevant extension set. If threatening to turn off OCSP was a necessary forcing function to achieve that end, well OK. I don't have an Internet Draft on this but I should have one soon and expect it to be short. ---------- Forwarded message ---------- From: Phillip Hallam-Baker <[email protected]> Date: Mon, Feb 6, 2012 at 2:16 PM Subject: Certificate flag for 'always stapled' To: [email protected] Discussions on the utility of various revocation mechanisms in another place arrived at the following problem identified in OCSP: While OCSP stapling is good for performance, it does nothing to address the problems that cause current browsers to (mostly) avoid hard-fail when a valid OCSP token is not returned since the client has no way to know if a TLS connection should have delivered the stapled cert or not. Proposal: Introduce a certificate extension that says 'valid OCSP token must be stapled when used with TLS'. Mechanism: If a browser supporting the extension sees a certificate presented in a TLS session it ignores any OCSP distribution point published in the cert and will only accept the cert if supported by a valid OCSP token using the TLS stapling mechanism. The extension SHOULD NOT be marked critical, legacy browsers will be unaffected and fail in the ordinary way. The extension would normally be generated in response to the extension being published in a CSR. A CSR generating app should only insert the extension if the server is configured to use OCSP stapling. A server should provide an operator warning if use of a certificate with the extension is attempted without stapling being enabled or alternatively turn on stapling automatically. -- Website: http://hallambaker.com/ -- Website: http://hallambaker.com/
