On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham <[email protected]> wrote: > On 16/09/14 23:13, Richard Barnes wrote: >> From a browser perspective, I don't care at all whether certificates >> excused from containing revocation URLs if they're sufficiently short >> lived. > > From a technical perspective, that is true. However, if we have an > interest in making short-lived certs a usable option, we have to > consider the ecosystem. CAs will have to do engineering work to issue > (and reissue) such certs every 24 hours, and sites will have to do > engineering work to request and deploy those certificates.
Changing a server to properly and safely support replacing its certificate on the fly is a very error-prone and difficult thing to do, compared to changing a server to properly and safely support OCSP stapling. For example, when the server updates its certificate, it needs to verify that the new certificate is the right one. Otherwise, the updated certificate could contain a public key for which an attacker owns the private key, and the server would be facilitating its own compromise by switching to that new certificate. In contract, with OCSP stapling, an attacker can never replace your server's public key, and so there is much less risk of catastrophe with OCSP stapling. Because of the added risk and added complication of short-lived certificates relative to OCSP stapling, and because OCSP stapling is already well-specified and quite widely implemented (though not yet commonly enabled), it would be better to prioritize shortening the maximum acceptable OCSP response validity period (e.g. to 72 hours) and to define and implement Must-Staple, over defining new standards for short-lived certificates. Those two improvements would have an immediate positive impact. Note, also, that browsers already effectively support short-lived certificates, even without any CABForum or browser policy work. And, also, I do support defining standards for short-lived certificates; I just think that fixing OCSP stapling should be a higher priority. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
