This is a discussion on Re: Accessing encrypted messages after cert expires - Openssl ; * 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 ...
* 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.
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 email@example.com
Automated List Manager firstname.lastname@example.org