Passwords: change them every 14 days because... reasons.
Certificates: change them every 397 days because... reasons.
If your password or certificate is compromised then it must be changed immediately. If your password or certificate is strong and not compromised there's no reason to change it.
Major sites still manage to forget to renew certificates (Ubisoft's Uplay PC client couldn't retrieve news a few weeks back because of this). Having shorter certificate lifetimes better forces sysadmins to ensure they're on the ball with the renewal, preferably in an automated (output checked by humans shortly after) manner. LetsEncrpt is great for this.
Major sites still manage to forget to renew certificates (Ubisoft's Uplay PC client couldn't retrieve news a few weeks back because of this). Having shorter certificate lifetimes better forces sysadmins to ensure they're on the ball with the renewal, preferably in an automated (output checked by humans shortly after) manner. LetsEncrpt is great for this.
Or... remove the expiry date entirely.
Other than cash-cow reasons, why do certificates ever expire? They are effectively just keys. Keys don't expire. If a key is compromised, you change the locks, which is the equivalent of revoking a cert. If a key is obsoleted, you upgrade the lock and issue new keys, which is the equivalent of a browser dropping support for legacy certs.
Once a cert is issued, there's no burden on the issuer, so why are we paying repeatedly for the product we already have?
I have similar views with regards to domain names. I mean... yeah, there's some infrastructural costs there but all the real traffic is at DNS. Domain registration should be a decade or two
The original reason there is some sort of expiry is to limit the size of the revocation lists. For example, all certificates in revocation that have expired can effectively be removed since they have expired. Without that limitation, every 'revoked' cert must remain on the list forever.
That being said, how many certs are actually revoked, versus certs that are simply abandoned, or the private keys lost. If the revocation lists are small anyway, there is no pressure to implement expiry.
An additional advantage or revocation is to limit the problem of poor data handling (eg. old servers being thrown out, etc) allowing potentially valuable certs to fall (unkowningly) into the wrong hands. Expiry doesn't prevent short term problems, but it does mean that an old system that final gets sent for 'recycling' (ie. landfill) is unlikely to contain anotherwise non-expired cert. Especially if expiry times are as short as 1 year.
The original reason there is some sort of expiry is to limit the size of the revocation lists. For example, all certificates in revocation that have expired can effectively be removed since they have expired. Without that limitation, every 'revoked' cert must remain on the list forever.
Hmmm, as I recall, x.509 certs had expiration dates built in from the original spec, and SSL/TLS capable browsers were always able to detect expired certs, but revocation lists were an afterthought that the browsers took fore
That is correct. The theory of revocation and the practical implementation were not aligned at the beginning. The design catered to both systems, with expiration being the online and offline usable last line of defence. Also, the clients/servers could simply use the expiration as a suggestion, and how and when they dishonoured the cert was browser specific. This allowed browsers to let the user optionally ignore expired certs and in more recent times allow browsers to force a maximum time limit that might b
because for revocation you have to check again. If you don't have access to the CRL, or actively check, you succeed where you shouldn. Expiry is the "safeer default", as a compromised cert is at most (in let's encrypts case) 90d valid.
If a key is compromised, you change the locks, which is the equivalent of revoking a cert
The goal is to ideally ensure that the key never gets compromised. To use your analogy imagine you have a lock but lock-pickers are able to work on picking the lock 24/7 without interruption - basically what happens on the internet. Done properly it's more secure to rotate the locks periodically than it is to keep the same lock until it gets picked. If you wait until it is broken to do anything then whatever you were protecting is already taken and it's too late. You are bolting the gate after the horse
You have a point, but it would take a "standard desktop" (as defined by Digicert) around 1.5 million years to decrypt a 2048-bit cert. https://www.digicert.com/TimeT... [digicert.com]
Let's be generous and round that down to a cool million years and give the bad guys a 1000 node cluster, and we are looking at 1,000 years to crack a cert. Looking at that, I'm comfortable with protecting low-value sites with a 2 year cert. Banks and credit card agencies should be more paranoid. I'm much more worried about someone compromis
To scale your lock analogy up to match the complexity of modern crypto... it really doesn't matter whether the lock-pickers can work 24/7 without interruption for one year or three, because it's going to take them a billion years on average to find the right combination.
You're more likely to drop the slip of paper with the new combination on it (or accidentally commit your private keys to a public git repo) than they are to crack the lock.
Similar problem, similar non-solution (Score:5, Interesting)
Passwords: change them every 14 days because ... reasons.
Certificates: change them every 397 days because ... reasons.
If your password or certificate is compromised then it must be changed immediately.
If your password or certificate is strong and not compromised there's no reason to change it.
Re: (Score:2, Informative)
Re:Similar problem, similar non-solution (Score:5, Interesting)
Major sites still manage to forget to renew certificates (Ubisoft's Uplay PC client couldn't retrieve news a few weeks back because of this). Having shorter certificate lifetimes better forces sysadmins to ensure they're on the ball with the renewal, preferably in an automated (output checked by humans shortly after) manner. LetsEncrpt is great for this.
Or... remove the expiry date entirely.
Other than cash-cow reasons, why do certificates ever expire? They are effectively just keys. Keys don't expire. If a key is compromised, you change the locks, which is the equivalent of revoking a cert. If a key is obsoleted, you upgrade the lock and issue new keys, which is the equivalent of a browser dropping support for legacy certs.
Once a cert is issued, there's no burden on the issuer, so why are we paying repeatedly for the product we already have?
I have similar views with regards to domain names. I mean... yeah, there's some infrastructural costs there but all the real traffic is at DNS. Domain registration should be a decade or two
Re:Similar problem, similar non-solution (Score:5, Informative)
The original reason there is some sort of expiry is to limit the size of the revocation lists. For example, all certificates in revocation that have expired can effectively be removed since they have expired. Without that limitation, every 'revoked' cert must remain on the list forever.
That being said, how many certs are actually revoked, versus certs that are simply abandoned, or the private keys lost. If the revocation lists are small anyway, there is no pressure to implement expiry.
An additional advantage or revocation is to limit the problem of poor data handling (eg. old servers being thrown out, etc) allowing potentially valuable certs to fall (unkowningly) into the wrong hands. Expiry doesn't prevent short term problems, but it does mean that an old system that final gets sent for 'recycling' (ie. landfill) is unlikely to contain anotherwise non-expired cert. Especially if expiry times are as short as 1 year.
Expiry was implemented before revocation, though (Score:2)
Hmmm, as I recall, x.509 certs had expiration dates built in from the original spec, and SSL/TLS capable browsers were always able to detect expired certs, but revocation lists were an afterthought that the browsers took fore
Re: Expiry was implemented before revocation, thou (Score:2)
That is correct. The theory of revocation and the practical implementation were not aligned at the beginning. The design catered to both systems, with expiration being the online and offline usable last line of defence. Also, the clients/servers could simply use the expiration as a suggestion, and how and when they dishonoured the cert was browser specific. This allowed browsers to let the user optionally ignore expired certs and in more recent times allow browsers to force a maximum time limit that might b
Re: (Score:1)
Re: (Score:1)
I'd like to see the GAP analysis of people typing on their phones without the full use of the shift key.
Management principle: write once well, efficiently skimmed many times by people who value their time.
Management principle: write once sloppily, consider yourself lucky to be read by anyone, ever who regards time as a precious commodity.
Re: (Score:1)
because for revocation you have to check again. If you don't have access to the CRL, or actively check, you succeed where you shouldn. Expiry is the "safeer default", as a compromised cert is at most (in let's encrypts case) 90d valid.
Wrong goal (Score:2)
If a key is compromised, you change the locks, which is the equivalent of revoking a cert
The goal is to ideally ensure that the key never gets compromised. To use your analogy imagine you have a lock but lock-pickers are able to work on picking the lock 24/7 without interruption - basically what happens on the internet. Done properly it's more secure to rotate the locks periodically than it is to keep the same lock until it gets picked. If you wait until it is broken to do anything then whatever you were protecting is already taken and it's too late. You are bolting the gate after the horse
Re: (Score:2)
You have a point, but it would take a "standard desktop" (as defined by Digicert) around 1.5 million years to decrypt a 2048-bit cert.
https://www.digicert.com/TimeT... [digicert.com]
Let's be generous and round that down to a cool million years and give the bad guys a 1000 node cluster, and we are looking at 1,000 years to crack a cert. Looking at that, I'm comfortable with protecting low-value sites with a 2 year cert. Banks and credit card agencies should be more paranoid. I'm much more worried about someone compromis
Re: (Score:2)
To scale your lock analogy up to match the complexity of modern crypto... it really doesn't matter whether the lock-pickers can work 24/7 without interruption for one year or three, because it's going to take them a billion years on average to find the right combination.
You're more likely to drop the slip of paper with the new combination on it (or accidentally commit your private keys to a public git repo) than they are to crack the lock.