On Sat, Mar 15, 2008 at 11:36 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > For example, suppose I create a public/private keypair that I don't think > anyone can break for 50 years. If I make the certificate valid for 30 years > because of this, it would obviously be a bad idea to keep the same key for a > new certificate. On the other hand, if I make the certificate valid for two > years because I can only assure that the identity in the certificate will > belong to the key owner for that long, there's no harm in re-using the same > key in the next certificate if I know the identity is good for another two > years. (The key being safe for 48 years rather than 50 is a negligible > difference, but don't renew the certificate for the same key forever.)
Arguably, you shouldn't do it even once, because it's extremely easy to fall into the pattern of "one key and one key only" in the systems design or implementation. I can't remember who coined the phrase, but it's not "good crypto hygeine". Granted, there are some circumstances where such a risk is acceptable [a different threat model than that used by vanilla X.509 or PKIX can render the risk a non-issue], but in general it should be avoided if possible. (and "there's not enough resources available to code it" isn't really a good reason for calling it "impossible".) -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
