On Wed, Mar 19, 2008 at 10:45 AM, Michael Sierchio <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
