On Sun, Mar 16, 2008 at 10:57 PM, Michael Sierchio <[EMAIL PROTECTED]> wrote: > David Schwartz wrote: > > > If you can't trust the system that generates and stores your private key, > you're screwed anyway. So I don't see that this argument has any validity. > > A timestamp is not an attribute of a private key. It's utterly > irrelevant. If your purpose is to require that new certificates > bound to an entity upon expiration of old certs have a different > key, do that. Multiplying your misunderstanding by zero does > not improve matters, even for large values of zero. > > - M
A key's lifetime is, cryptographically speaking, the amount of time for which it can be expected to provide a sane level of security in relation to the value of the data which it protects. Of course, cryptography is just a means of applying a policy to a piece of data. If you share a means of decryption, you also share a piece of trust with whomever you share that means with that they won't violate that policy, even though the policy is advisory (i.e., non-enforceable) once the data is decrypted. A 'creation time' is an attribute of a private key, but it is an attribute which only the key generator and possibly the CA have any reason to find useful. A CA imposes a policy of maximum usage period upon a given identity binding for that key (and puts this in the certificate of identity binding). A key generator imposes a policy of maximum usage period upon a given key, regardless of the valid period of identity binding. Having the timestamp associated with the private key, then, is something that the generator has an interest in. Not having this field as part of PKCS#12 (since, arguably, only the key generator or someone authorized to act on the key generator's behalf has any reason to look at an actual decrypted pkcs12 structure) is, thus, a failure of the format. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
