On 9/3/13 8:55 PM, Yoav Nir wrote:

I agree with Stephen that key rollover would never be frequent enough to 
provide meaningful FS. It's also likely that a country where court orders for 
RSA keys get issued will also have laws requiring companies to retain old 
private keys for a certain period of time, just as there are laws requiring the 
retention of certain documents and correspondence.

With the current CA business model, probably not. But in theory, if things were changed so that keys could be rotated every month, every day, or potentially every hour, then that could provide meaningful FS.

I'm not aware of any laws in the US that require old keys to be kept. So if the NSA came knocking, they could compel you to turn over current (and possibly future) keys, but if one had already erased one's previous keys, that would keep prior communication safe.

Also, legal means are not the only way a state actor (or non-state actor) could acquire a private key. They could use zero-day exploits to break into a computer in another country (or, depending on their morality, in their own country) and obtain the private key. Frequent key rotation would ensure that any communication that had happened prior to the break-in would be safe.

Is seems to me that using ciphersuites with PFS, whether ECDHE or DHE, would be 
a better way. Google is not implementing it at scale on their servers. All 
browsers support some ECDHE ciphersuites, and they're also supported in 
libraries such as OpenSSL. So PFS is just a configuration away. Easier than 
manually or automatically rotating certificates often, no?

Yes, I do think PFS ciphersuites are a better way. Although sometimes I've heard "performance" given as a reason for not enabling PFS. In that case, frequent key rotation (if the CAs cooperate) would allow much of the benefit of PFS, at essentially no additional computational cost.

--Patrick

_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to