On Wed, Mar 19, 2008 at 10:45 AM, Michael Sierchio wrote:
> Steffen DETTMER wrote:
> > For operational, administrative and forensic concerns I think it
> > is important to know the key generation time as well as who
> > generated it in exactly which way, who gave the key to whom when
> > and why and so on - maybe even including a transactional log of
> > every key usage ever done.

> 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.

If you have to handle management separately, then you increase the
amount of error that can creep in.

> For compliance purposes, how do you prove generation time? 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 you want to 'prove' a generation time, use a timestamping service
like Verisign's timestamps. However, we're talking about ways of
making it operationally easier to administer and operationally easier
for devices to cry out 'hey, we're using a key that's coming up on its
expiration' -- defined by a delta calculation on the device itself,
NOT an enforced "key expiration" date defined at generation time.

> If the timestamp isn't generated by a trusted third party, I don't
> think it's of much value.

Remember: the private key is only ever read by the entities with
ultimate trust, by definition. If you can't trust yourself, who can
you trust? If no third party is ever going to see the timestamp, why
should it matter if it's generated by a third party?

A key can be separated from its timestamp and a newer timestamp
applied to it. It can be separated from its timestamp and an older
timestamp applied to it. But, under the rules of PKCS#12, the person
doing so must be able to decrypt it to have access to it in order to
do so -- meaning, they either have to be authorized to decrypt it or
break the container cipher or MAC.

Why can't metadata about the key be included in that container, just
to avoid some of the bookkeeping hassles? Like, how do you know which
key you've exported into a particular file? By the filename? What
happens when your directory structure gets hosed and chkdsk or fsck
finds it and puts it into lost+found? Once it's there, how do you
figure it out?

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