Michael Sierchio wrote:

> I'm not suggesting that this isn't useful, just that it is not
> a defect that it isn't part of the key format itself.


That may or may not be true, but none of your arguments support this =
point.

I'm learning towards a belief that it is a defect, but I am not =
thoroughly convinced and in any event, am not enough of an expert that =
anyone should act on my views.
=20
> For compliance purposes, how do you prove generation time?


For compliance purposes, how do you prove you didn't publish the private =
key in an ad in the New York Times or that the private key generator =
didn't generate a private key an adversary programmed it to generate? =
How do you prove it didn't generate the same private key before? If you =
don't trust the system that generates and stores your private key, =
you're screwed anyway. (With or without a timestamp.)

You simply have to trust any system that sees your private key. That =
doesn't mean you have to extend it unlimited trust, of course. But =
trusting it to properly generate and store the timestamp is =
substantially the same type of trust for a lesser purpose.

> I claim
> that the relevant time is that of the first CSR. Operationally,
> a timestamp and a nonce as part of a challenge created by the CA,
> included in the CSR which is signed by the subject privkey, makes
> sense. And hygiene dictates that the only use of the private
> key permissible before issuance of the certificate is in signing
> the CSR.
>=20
> If the timestamp isn't generated by a trusted third party, I don't
> think it's of much value.


The only real threat model would be that the key was available earlier =
than the timestamp, and trusting that the stamp was generated at the =
time it claims won't help with that.

I think I would go further and argue that not only should a generation =
timestamp be included in private keys but that a key validity interval =
(signed by the corresponding private key) should be a standardized =
option for certificates.

If your argument is "the key generator's clock could be broken", I would =
respond, "the key generator's RNG could be broken too".

DS


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org