Kyle Hamilton wrote:
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.
Right, which is a matter of consensus best practice, we hope...
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.
I think you need to be more careful about what is trusted. In the case of a signed message, our trust depends on a number of things -- that the message was signed during the validity period of the signer's cert, that the cert declares the key to be valid for that use, and perhaps trust in the CAs policy enforcement and revocation methods, CRL publication, etc. We trust that, absent a key revocation for any reason, including expiry, that a private key remains under the exclusive control of the signer. Signatures might require third party digest timestamps for non-repudiation of the validity of the signature wrt time of signing prior to a trusted date. Anyway, in the case of RSA keypairs we don't manufacture them, we discover them. They're already there, we just search for our p's and q's in the appropriate range and rely on chance starting conditions to find some not in use. I suggested, but not entirely in jest, giving them all a timestamp of 0. Creation date is a useless concept. Not valid before and Not valid after attributes make enormous sense, and are where they ought to be. The trust conferred on a signature derives from signature validation, which requires certificate validation. One part of the validation is that the message in question was signed during the validity period as defined by certificate policy. You may argue, and get me to agree, that cert reissue/resigning with the same SubjectPubkeyData is a bad idea. Make 'em generate keypairs. Keep a list forever of pubkeys seen in certs and reject any that appear in CSRs. Your storage requirements won't rival that of Youporn, or Wikipedia. b ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
