+1 Short lifetime certs don't solve every problem with revocation. But they allow us to drastically reduce the problem space. That makes applying other mechanisms viable.
The end goal has to be to reduce the time window of vulnerability to the time it takes people to respond to phishing sites and other attacks. That is minutes, not days. We are not going to get there soon. But that is where we have to aim for. On Fri, Sep 5, 2014 at 12:43 PM, <[email protected]> wrote: > Hi Gerv, you've been busy! > > The cases Jeremy identified (thanks, Jeremy!) are all good problems to > address and while I'm not unsympathetic I don't necessarily find them all > that compelling. The situations involving network meddling by someone in > power is especially troubling and goes beyond what I'm interested in > covering in this discussion. > > That said, the case for performance is troubling for a couple reasons. > First is that I've seen many times where someone says "(whatever) would > work so much better if we could bypass this security stuff". I don't mean > to suggest that people who want small cert chains are wanting to bypass > security but a practice such as this does open the door for people who > might consider such things. So my initial concern is where this might lead, > and what protections might be needed to ensure it doesn't go further. > > The bigger problem I have with this, however, really has nothing to do > with people who have good server configs and are competent server admins. > In such cases, we can probably assume there are likely to be fewer mistakes > made and thus less of an impact to security. > > My problem is what happens when the cert holder loses control of the > private key, no matter what the reason is. Relying on the expiration date > is only a partial answer for 2 reasons: 1) a user might choose to allow the > expired cert with the compromised key anyway (hence my asking about its > treatment); and 2) a short expiry might still be long enough to cause harm. > Consider that a phishing site might only exist for 2 days, just as an > example. > > So in order to safely proceed with a small cert solution I think we need > to flesh out how key compromises can be mitigated. > > > *From: *Gervase Markham > *Sent: *Friday, September 5, 2014 4:47 AM > *To: *[email protected]; Jeremy Rowley; > [email protected] > *Subject: *Re: Short-lived certs > > On 04/09/14 19:32, [email protected] wrote: > > Could you (or anyone) elaborate a bit on the use cases where short > > lived certs are desirable? > > See other messages in this thread - it saves a significant amount of > setup time not to have to wait for a response from the OCSP server. > > > I'm also wondering what the plan is for handling an expired short > > term cert. Will the user be given a choice of allowing an exception > > or does it get special handling? > > What if I say it's treated the same as any other expired cert? > > Gerv > > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
