Jason Haar wrote:
<soapbox>
This is something I noticed before too - and appears to be a real "failing" with PKI. Although by "failing" I mean "not what end-users expect"...
Let's assume the whole world has embraced PKI and everyone is sending/receiving S/MIME encrypted e-mails. How are we (as a society) meant to handle "old" e-mails - when by definition there is a lifespan associated with any certificates used in them?
And while we are on the soapbox, I never understood why there is a lifespan associated with me anyway! ;)
The lifespan of a certificate only defines the timespan during which it is valid to sign or encrypt with it. It says nothing about when to verify or to decrypt. And what's the problem to keep a certificate (which uses a kilobyte of memory) with the messages after it is expired?
A different spin on the same problem: my cert gets stolen/compromised. I get my certificate revoked. Now no-one trusts my old e-mails - sent and signed by me before the cert was compromised?!? You may argue that is a MUA S/MIME implementation issue - but it's true today for the MUAs I've tried.
That's the reason why you use certificates with a limited lifespan. So if your current cert is compromised at least the mails signed with the old mails are still valid!
And, btw, if there is a reliable way to assure when the signature has been generated (for example using a timestamping service, or less elaborate, the time when you received the message) there is no reason to doubt signatures which have been generated before the cert was revoked! But I agree, this IS a MUA implementation issue. And an issue of assuring signature timestamps.
What is the purpose of the expiry date on a S/MIME cert anyway? If you had a cert with a 10000-year expiry date, *and you know it was never compromised* - then that fixes these sorts of problems. Is there any downside to that? As far as S/MIME is concerned (IMHO time-limited certs do have a place in other roles), if the safety of the cert is assured, then maybe we should have huge expiry dates on them?
If you can assure the safety (that is, trust your users), this may be the way of doing it. It's just a risk optimisation, where risk is the product of "probability of damage" and "amount of damage done". Maybe you also noticed, that many CA-certs have rather huge expiry dates... ;)
The idea that you have to renew/get new certs for crypting e-mails (documents in general?) doesn't "seem right" to me...
AFAIK it comes from the idea that it is never possible to assure 100% security. What if tomorrow some genious finds a way of qickly factorising products of large primes (they hope to be able to do that with quantum computers)? Then your 10000 year expiry on a RSA-key may only last 10 years. And given enough time every key can be broken brute force. OK, there are some who say even the universe has a limited lifespan... ;)
I mean, as far as a usercode goes, as long as you have a right to access (say) a company network, your usercode is static. Your password that protects that usercode should be changed on a regular basis - but even that is really to *limit the length* of a compromise more than stop it being compromised in the first place.
And how do you handle the situationwhen someone manages to copy your (encrypted and password protected) secret key? This one would not be very impressed by you changing passwords (on your copy anyway).
Maybe we should ensure apps focus more on private key protection than try to get the certificates via expiry dates to do that job? (and yes, that can always be worked around as the end-user controls everything in the case of a cert)
As I tried to show, it's just the amount of paranoia hounting your brain. Noone prevents you to issue user-certificates with a lifetime of 20 years. But don't believe that you can make me trust your CA-cert if the protected data is valuable enough.
</soapbox>
Hope this helps, Ted ;)
-- PGP Version: 2.6.3i Public Key Information Download complete Key from ftp://ftp.convey.de/ted/tedkey.asc Key fingerprint = 26 A9 0C 25 60 15 2C B2 D0 F3 A2 31 3D 35 F3 95
smime.p7s
Description: S/MIME Cryptographic Signature
