This is a discussion on RE: Accessing encrypted messages after cert expires - Openssl ; 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 ...
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 =
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.
> 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.
> 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".
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org