Coming in late to the party... This discussion seems pretty wildly off-target to me, at least from a browser perspective.
>From a browser perspective, I don't care at all whether certificates excused >from containing revocation URLs if they're sufficiently short lived. 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. >From a CA perspective, though, I can see how this is important, since it lets >you reduce the load on your OCSP server, or maybe even get rid of it. So in units of Gerv's options below, the only action for Mozilla is (2). 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. --Richard On Sep 4, 2014, at 6:21 AM, Gervase Markham <g...@mozilla.org> wrote: > Short-lived certs are one plank of our future revocation strategy.[0] > Currently, it is not permitted by the CAB Forum Baseline Requirements to > revocation pointers out of a cert, ever. However, this is part of the > big value of short-lived certs, as it's what unlocks their > speed-increasing potential across all browsers. (The logic is that a > 3-day expiry misissued cert with no revocation pointers has a similar > risk profile to a 1-year expiry misissued cert where the attacker has > captured a valid 3-day expiry OCSP response they can staple to it). > > I've just been reviewing discussions from July 2012 on the CAB Forum > mailing lists about short-lived certs. There was some significant > opposition to removing revocation information from short-lived certs at > the time (although things may be different now, I don't know). I > personally think much of that opposition was mistaken, but the > discussion nevertheless did not result in consensus. > > How should we approach the issue of short-lived certs? It seems to me we > can do the following: > > 0) Try and get a motion passed to change the BRs to allow short-lived > certs to not have any revocation information. This would probably > require us to review the original discussion and make a wiki page > outlining our proposal and rebutting objections. We may still run into > heavy weather. We could also discuss it at the face-to-face. > > 1) Write an exception in Mozilla's policy that short-lived certs don't > have to have revocation info. This would likely have no effect, because > CAs would want to continue issuing to the BRs. > > 2) Stop checking revocation information for short-lived certs > unilaterally. This would result in reduced take-up of the idea, because > there would be no advantage in other browsers, and one would still need > to implement all the mechanisms, both at the CA and at the site, for > frequent cert renewals and deployments. > > 3) Configure Firefox to not bother checking revocation information for > any cert newer than N days. This way, you can "emulate" short-lived > certs by just reissuing an X-year cert every N days or less. It also > 'fixes' the clock-skew problem in one direction, because the certs will > still work for users whose clocks are some way in the future (although > their browsers would check revocation). > > 4) Something else? > > Gerv > > [0] https://wiki.mozilla.org/CA:RevocationPlan > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
