Michael Sierchio wrote: > 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.
Nonsense. An attacker can start trying to break your key as soon he has your public key. You can put an earliest-possible bound on this -- he cannot have started before you generated the key. A creation timestamp on the private key that's placed by whatever generated the private key would serve as an earliest bound for when at attempt may have been made to break the key. The not valid before and not valid after attributes specify the outer bounds by which the certificate can be used to bind the private key to a name. This must be the lesser of the validity interval for the key itself and the validity interval for the binding. Often the binding is less, so this does not tell you a safe validity interval for the key (other than that it's valid at least as long as the certificate is). The certificate validity period tells you something different from the validity interval for the key. Plus, a single key may be associated with any number of certificates all of which have different validity intervals. A key may be associated with no certificate at all, if it doesn't need to be bound to an identity in that way. In all these cases, a creation timestamp in the public key would serve to inform of the expected validity interval of the key. An alternative way to accomplish the same thing (that some might like better) is to store public keys with self-signed (by the corresponding private key) certificates, with the validity of that certificate being the key's validity. I've done this, but it feels kind of like a hack. > 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. Sure. But another part should (at least in some cases) be that the validation is performed during the key's validity interval. After all, you would be foolish to trust a 512-bit RSA key signature from five years ago in twenty years. (But that's another issue entirely, I suppose.) > 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. It's sometimes a bad idea and sometimes a good idea. Sometimes it even makes sense to issue multiple certificates for the same keypair. X.500 is not just for TLS. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
