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. Whether those things are worth doing depends on the gain you get. If the improved speed is only for a small population of browsers, it is probably a lot less worth it than if it makes things faster for almost everyone. The latter is only achievable if it's permitted to remove the revocation pointers. I can look at the validity interval and make a decision to > check revocation or not, regardless of whether the OCSP URI is there > or not. In fact, a short-lived cert with an OCSP URI gets the > benefit of added speed from browsers that suppress OCSP for > short-lived certs, while at the same time working with legacy > browsers. A short-lived cert _without_ an OCSP URI also works with legacy browsers. Unless you are using some other definition of "works"? > So in units of Gerv's options below, the only action for Mozilla is > (2). As I noted, "this would result in reduced take-up of the idea". > We could do (0) in addition, or support similar efforts by CAs > to get the BRs update to let them out of OCSP obligations for > short-lived certs. Honestly, I would prefer if CAs led, since > they're the ones that benefit. If this is something we want to be part of our revocation strategy, then we benefit if we make it attractive to sites and CAs. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
