* Michael Sierchio wrote on Tue, Mar 18, 2008 at 17:01 -0700: > > ... It specifies things that third parties can know and rely > > on. Only the principal itself can know what it's actually > > going to use the key for. > > No, key usage restrictions are certainly within the realm of > what a CA will bake into a cert. And relying parties may > choose not to accept a cert for a given purpose if that purpose > is not included in key usage extensions, for example.
Actually it depends on the party that accepts the certificate. Even if the CA tells that the particular key must not be used to sign certificates, some party may accept it anyway, because this party defines its policy. The key and attributes of it might be stored in a hardware security module that automatically overwrites the key with random data when it is expired. Regardless how many different and contradicting certificates exist. Maybe several such modules are needed and thus some secret key transfer may be needed - including transferal of some timestamp to make the hardware security module know when to erase the key. The key owner is the boss of key expiry, not any CA. I think this is even true in the `browser world'. If I generate a key and buy a Verisign certificate, I won't let verisign decide when I expire my key, because it is my key. Verisign may say CA:FALSE but my `own CA' may certify CA:TRUE. Maybe my key is used in different applications that do not even support X.509. The CA should care about the identity and its relation to some key. Of course it is reasonable to protect for some mistakes (like using too weak keys), but on the secret key much higher security requirements may be applied to that the CA requires. For instance, a key validity of 30 days or 100 decryption blocks of data whatever comes first (e.g. ensured by a hardware security module). > Irrelevant to the discussion -- I was arguing against adding > time of generation data to the private key format. I don't > know of any serious cryptographer or security expert who > advocates this, and I certainly don't. I could imagine that this would be interesting, including other attributes. However, if they are not part of the key format they can be transmitted separetely. I think a question is whether those attributes are general/common enough to be included in some private key format specification. 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. It might be required that the security officers maintain such kind of documentation on some non-changeable media for instance printed on paper. If e.g. keys older than 12 month must not be used, systems could verify that automatically to avoid mistakes or to detect security problems. If keys are transferred between such systems, having the needed attributes in some key exchange format (or message, file, hardware security module) seems reasonable. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
