On 9/8/11 11:20 AM, Zack Weinberg wrote: > On 2011-09-08 10:57 AM, Daniel Veditz wrote: >> Yes, OCSP supposedly traded off a little privacy for immediacy over >> CRLs. Except that many OCSP deployments in practice just respond >> based on the data in the CRL. > > Peter Gutmann posted a draft OCSP replacement in the DigiNotar > thread over in s.policy: > > I skimmed the spec and didn't see anything directly relating to user > privacy, but if we're thinking about revising OCSP for privacy's > sake, it might be easier to start from something like this.
I saw that, too. But we're not starting from scratch by revising OCSP, we mainly just have to make changes to Firefox. If we did something like I outlined we'd have a better story with or without stapling. If sites wanted to implement stapling on top of it (which at least some popular web server software already supports) then so much the better. --Most-- importantly none of those improvements require the CAs themselves to do anything. Implementing a new protocol requires work from everyone involved: browser vendors, sites, server software vendors, and CAs, and CA-server software vendors. There are some complaints about stapling because it only supports stapling a single OCSP response, and for a first visit you need to check OCSP on the intermediates too. But single stapling is still an improvement in both latency and privacy. This is definitely a case where worse is better, especially in the short run. Gutmann's alternative is a long-run play. -Dan Veditz _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
