On Sun, Sep 28, 2014 at 10:59 AM, Leo Vegoda <[email protected]> wrote: > Hi Phillip, > > On Thu, Sep 04, 2014 at 12:51:27PM -0400, Phillip Hallam-Baker wrote: > > [...] > >> First off, I assume that each participant has at least one personal >> PKI which for the purposes of this discussion we can consider to last >> their lifetime. > > Does this mean that each person needs to create a key that will > remain cryptographically secure for the duration of their life? Is > it practcal to expect a key created today to be cryptographically > secure in 2074?
No, the expectation is not that the key will be secure lifelong. The point is that the architecture does not assume that problems can be solved by waiting for it to expire. Assuming email certs expire annually really sweeps most of the hard problems under the rug while making the system unusable. Obviously, there has to be a key succession scheme. But checkpointing the keys in a Trans like architecture allows a lot of problems to be avoided. The transition scheme would be something like, generate the new stronger key, sign it with the old, get the transition statement notarized in the Big Log. > Separately, how practical is it to expect non-geeks to keep their > private key safe but accessible when necessary for multiple decades? Quite practical if the problem is posed in that way. First, lets reduce the problem by encrypting the private key and storing it in the cloud. Now all we need to do is to manage the decryption key, which is a lot fewer bytes. We can print that out on paper. We can do key splitting into 2 shares or 3 of 5 or whatever. The part I have not worked out yet is how to manage escrow of decryption keys. Which is an essential requirement that is in conflict with other requirements. It is easy enough to make a scheme escrowed or escrow free. What is hard is to allow the user to easily choose between them. _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
