Hi, interesting thread.
I also think that secret and shared keys have attributes as creation or validation date. One very important attribute I would like to mention is the "is revoked" attribute. Of course certificates also can be revoked, but this is something different. Revoked certificates can be renewed but revoked keys cannot be (would not be reasonable). Of course peers must trust (`believe') that the peer stores its key correctly and securely depending on the policy, that it is kept secret and that it is replaced by a different key if needed and that much entropy is used and so on and so forth. All this IMHO is independent whether a CA or some certificates are used at all. Also, someone could implement some key continuity management (or however the correct term was) like e.g. SSH does. For initial key exchange maybe a certificate was used, but the key can be trusted independently of it as long as it is know to be authentic. Beside storing certificates, someone could simply store the key hash (together with attributes - and here it is!) in some trust.db file or so. If the requirement is to replace a key each 365 days, I think it obviously is a key attribute but not a certificate attribute. I think, a certificate is to bind a public key to some `human understandable' identity (or a `machine verifyable' such as some DNS name in some CN field, but I doubt that this is really `clean'; it seems a little bit pragmatic. For the human user at least a DNS name is not interesting. It is interesting whether it really is e.g. ebay, whatever DNS name they use.). Also, the security levels can be different. For instance, you could have a cacert.org email-verified certificate for a high secured key which is stored on a hardware security module in a safe in Fort Knox. Someone could trust the cert, others may not but could trust the key by other means. Also, a third could create a CA, certify this key with any certificate attributes. If the hardware security module automatically erases the key after lets say 12 month the certificates will still exists. A peer seeing an expired certifcate usually cannot determine whether the key can be trusted or not (maybe some other certificate exists). The peer may not trust the key (or tolerate the expired certificate for some days or reload the appropriate CRL or ask some user). This `not trusting the key' IMHO must not be persistent, especially in case of expiry of a CA or self signed certificate (but in practice, many CAs have root certificates valid for 20 years or so). All of that IMHO has no impact on the key itself, its validity definition/requirement/policy remains unaffected. About the subject `Accessing encrypted messages after cert expires' I think this is perfectly OK. This is a complex topic of course. Theoretically, even if the key was compromised there may be cases where the message can be trusted anyway (if it is known/ensured that the message was received before the key was compromised). I think in general when a key or all its certificates are revoked, usually the messages signed by it remain valid. Otherwise I think it would be some logical dilemma... David wrote: > An alternative way to accomplish the same thing (that some > might like better) is to store public keys with self-signed (by > the corresponding private key) certificates, with the validity > of that certificate being the key's validity. I've done this, > but it feels kind of like a hack. For me this also feels like a kind of hack. I guess key attributes simply were `forgotten' in some key exchange standards. I guess, in X.509 environments, lets say SSL secured web, usually, they don't matter as it is used (i.e. no key continutiy management but browsers including lots of CAs not directly known to the user, maybe audited or maybe not even with a public accessible policy, but noone seems to care). In other environments this may be different. Maybe keys are transferred encrypted under strong transport keys which are transferred independently - with attributes like key hash, validity dates, usage purpose but also some identifier or `key name'. > > The trust conferred on a signature derives from signature validation, > > which requires certificate validation. One part of the validation is > > that the message in question was signed during the validity period > > as defined by certificate policy. > > Sure. But another part should (at least in some cases) be that > the validation is performed during the key's validity interval. > After all, you would be foolish to trust a 512-bit RSA key > signature from five years ago in twenty years. (But that's > another issue entirely, I suppose.) BTW, why shouldn't a CA certify 512 bit RSA keys for 20 years? If the security level of the policy is more or less just for transport reliability or for some very limited embedded environment, I think it could be certified that this (weak) key belongs to the named identity. A peer may trust the CA and the CA may use a 4096 bit key. However, the same peer may refuse communication because of the key length or because of the weather. I think, trusting a CA simply means trusting that it generates certificates as defined in the policy and nothing else. The policy may allow email based certification without dual control or put serious security requirements. Also I would like to mention that even when trusting a CA this does not require to trust ALL certificates issued by that CA. Unfortunality, this is what browsers by default do and thus maybe people assume to be the only truth, but I think it is wrong. This is visible in many details, for instance, when doing online business (ebay or whatever), usually browsers display the URL but not the identities (subject and issuer) from the certificate. CAs have different security levels, but this is not visible. Countries have different security levels (for instance, one may forbid strong cryptography!) but this is also not visible. When you print out a HTTPS loaded HTML page, browsers may print the URL in some header or footer line but I never saw that by default security information was printed out. By this (the absense of cryptographic information like certificate and some document signature / hash) actually you cannot prove that this hardcopy is authentic! The CA can certify some bad guy (with correct DN telling that it is a trojan horse delivery company, or some rootkit provider like Sony SCNR) and IMHO this is absolutely correct. What not correct is would to trust this peer. All that can be trusted is that it really is the bad guy and no good guy would be able to read the exchanged messages :-) > > You may argue, and get me to agree, that cert > > reissue/resigning with the same SubjectPubkeyData is a bad > > idea. Make 'em generate keypairs. Keep a list forever of > > pubkeys seen in certs and reject any that appear in CSRs. (CSR? Is this like a CRL or something logically equivalent meant?) > > Your storage requirements won't rival that of Youporn, or > > Wikipedia. I think this is wrong. A CRL entry revokes a certificate, not the key. Maybe the certificate was revoked because of formal reasons (forgotten critical extension CA:FALSE or omitted key usage information or whatever). Maybe other valid certificates exist for this valid key. If I wrote wrong things and/or made logical mistakes, please correct me. > It's sometimes a bad idea and sometimes a good idea. Sometimes > it even makes sense to issue multiple certificates for the same > keypair. X.500 is not just for TLS. Yes, and TLS is not only for HTTPS... There are applications that only trust a very few peers each one knowing each other, but for technical reasons (e.g. SSL is known, standard, available, ...) don't use shared keys but some PKI with a special dedicated CA or even self-signed certificates for each key - just to make SSL working. Of course this puts requirements on key and certificate management, but if done well it can be very secure. It might make sense to simply resign the self-signed certs with new dates from time to time. Maybe it is required to maintain lists of the peers (where they are located, whom is using them, how often they used the keys or whatever) and know the life cycle. Maybe certificates with short validity dates are used to enforce that the peers communicate with some key (security) management or get out of order, technically enforced because of no existing valid certificate. 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]
