6 ms·

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the qual

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?

tmpz22 7y ago
Millions of dollars in IT consultation work. Target in 2014, 2019 (it was a 5 year certificate), Microsoft Teams 2020, etc.
marcosdumay 7y ago
Well, it's the one that works in practice. The issuer is the one that known when he will renew the certificate. If every client decided for himself, half of the internet would be broken at each time.
FireBeyond 7y ago
1. As an analogue for password expiration (with all the commentary that entails). 2. Recurring revenue models for CAs.
wool_gather 7y ago
> the issuer [...] are saying that they can't guarantee that they will still be the only person with the secret key after that point. It's not quite clear what you mean here. The issuer should never have the private key for the end-entity cert (the one representing the domain or whatever). Only the owner should have the private key. EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes. If you are talking about the CA's own private key...if that ever leaks, then no certificates signed by it should ever be trusted again; expiration date has no relevance here.
- tgv 7y ago
  The latter did already happen: Diginotar, in 2011. The Dutch government tried to restrain browser makers from revoking Diginotar's certificates, since many of their websites and services used them. It's a good thing certificates don't have an eternal life span.
- tialaramex 7y ago
  > EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes. I wasn't able to find this comment, but perhaps I didn't look hard enough? EDIT: Wait, I think I found it. I will reply there. In the Web PKI this is prohibited but there are or at least were resellers who'd offer this service to their customers. You should not use this service of course, and some CAs have pledged to tell their resellers not to offer it. In S/MIME it's more common because often the end user is both technically unsophisticated and not given real control over their client in order to mint their own keys anyway. But S/MIME is... probably not important, certainly it isn't what Apple's change is about.
simias 7y ago
Without an expiration date the only way to retire a certificate would be to explicitly revoke it. That'd be a bit heavy handed IMO. Forcing certificates to expire means that domain ownership gets re-validated every time. Nobody would risk buying 2nd-hand domains for anything sensitive if the previous owners could have a permanently valid certificate stashed somewhere. Or you'd have to contact all the CAs that could've issued a certificate for that domain and ask them to revoke it if they did.
- Reelin 7y ago
  Is there not already a standard procedure for certificate revocation on domain ownership transfer? It seems like there really should be - even a 13 month expiry is hardly enough to prevent intentional abuse.
  - tialaramex 7y ago
    "Standard" is a big ask. If this is a concern then you can proceed as follows: 1. Wait 24 hours or so after securing control over the names. 2. Use the Certificate Transparency logs to determine which certificates if any exist for names you now control and want revoked. 3. Discover the revocation process for the issuer of each cert. 4. Use each process you discovered. All of them should be willing to revoke if you can prove you now control these names. Some (Like Let's Encrypt) offer an automated way to do this, for others you may end up talking to a Customer services person or using an email ticket queue.
    - Reelin 7y ago
      Thanks for another clear explanation of process! But... the fact that there isn't some standardized automated revocation procedure that all CAs are required to support at this point seems somewhat absurd to me. At a minimum, it seems like such processes based on both proof of domain ownership and proof of private key possession should exist. Moreover, there ought to be a way to specify via DNS which CAs can issue certificates for your domain (I guess DNSSEC DANE will provide this?).
JoshTriplett 7y ago
If a certificate never expires, revocation lists have to grow without bound forever. If a certificate expires, revocation lists only have to hold revoked certificates that haven't expired.
tialaramex 7y ago
The issuer shouldn't know the private (not secret) key corresponding to the public key in the certificate anyway. In the Web PKI they're explicitly forbidden from knowing this key and good ones will react to being shown a private key by revoking any associated certificates -- that's what happened in the Trustico incident. They do know a private key for their entire CA certificate which they're using to sign things, but that's not what the expiry date in the leaf certificates they issue you is about. Nor is it intended that the lifetime of a certificate reflects the expected time to break the private key the user knows, otherwise Apple would let you have say a two year certificate if you went to P-384 certificates because they're harder to break in theory. There is obviously a threat over time that your keys leak ("Oops, the backup tapes I put in the trash have our current keys") but that's hard to assign a specific time interval to, it just means you should definitely change keys sometimes. The main thing that we're always worried about on a specific timescale is the name information. The same people control google.com today as two years ago, and likewise for my.lovely.horse but how about bobs-exhausts.example ? But the main impetus for desiring shorter lived certificates is that the certificate lifetime in practice constrains our ability to make technical changes like the SHA-1 deprecation. We'd like to make changes faster, and if you've just bought an 825 day certificate realistically our changes can't be effective in less than 825 days unless we're willing to be so disruptive your apparently valid cert ceases to work in popular browsers, which will be a hard thing to sell for merely precautionary changes.
- Reelin 7y ago
  I agree with your overall point and appreciate the clear explanation. However, I'd like to suggest that perhaps what you describe as "merely precautionary changes" should never occur on anything less than a ~2 year timescale anyhow. If it's urgent, go right ahead and break things. But the internet is _big_, and modifications can be _expensive_, so precautionary changes should probably occur quite slowly at this point.
zaat 7y ago
One effect of expiration dates is shorter revocation lists - if a revoked certificate was originally valid forever, the revocation list should list it since it was revoked to the end of times. Short lived certificates results in shorter CRLs. Lengthy CRLs have performance cost, they need to be downloaded and processed by clients. There is also a growing risk correlated to certificates validity length. If CRLs are unavailable to a client, the CRL server might be offline or unreachable or the client's access is maliciously blocked. The client have no knowledge of the reason and need to decide whether to trust the certificate without CRL check or not. If clients would be configured not to trust in such cases, the path to DOS is clear - block access to the CRL server and you effectively block traffic to all services of that CA. If clients are configured to trust certificates when CRLs are unavailable, which I beleive is the default on all OSs currently, blocking access to CRLs allows attacker to fool clients to trust revoked CRLs. With short living certificates, the opportunity window for such attacks is smaller.

tmpz22 7y ago

Millions of dollars in IT consultation work. Target in 2014, 2019 (it was a 5 year certificate), Microsoft Teams 2020, etc.

marcosdumay 7y ago

Well, it's the one that works in practice. The issuer is the one that known when he will renew the certificate. If every client decided for himself, half of the internet would be broken at each time.

FireBeyond 7y ago

1. As an analogue for password expiration (with all the commentary that entails). 2. Recurring revenue models for CAs.

wool_gather 7y ago

> the issuer [...] are saying that they can't guarantee that they will still be the only person with the secret key after that point. It's not quite clear what you mean here. The issuer should never have the private key for the end-entity cert (the one representing the domain or whatever). Only the owner should have the private key. EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes. If you are talking about the CA's own private key...if that ever leaks, then no certificates signed by it should ever be trusted again; expiration date has no relevance here.

tgv 7y ago
The latter did already happen: Diginotar, in 2011. The Dutch government tried to restrain browser makers from revoking Diginotar's certificates, since many of their websites and services used them. It's a good thing certificates don't have an eternal life span.
tialaramex 7y ago
> EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes. I wasn't able to find this comment, but perhaps I didn't look hard enough? EDIT: Wait, I think I found it. I will reply there. In the Web PKI this is prohibited but there are or at least were resellers who'd offer this service to their customers. You should not use this service of course, and some CAs have pledged to tell their resellers not to offer it. In S/MIME it's more common because often the end user is both technically unsophisticated and not given real control over their client in order to mint their own keys anyway. But S/MIME is... probably not important, certainly it isn't what Apple's change is about.

simias 7y ago

Without an expiration date the only way to retire a certificate would be to explicitly revoke it. That'd be a bit heavy handed IMO. Forcing certificates to expire means that domain ownership gets re-validated every time. Nobody would risk buying 2nd-hand domains for anything sensitive if the previous owners could have a permanently valid certificate stashed somewhere. Or you'd have to contact all the CAs that could've issued a certificate for that domain and ask them to revoke it if they did.

Reelin 7y ago
Is there not already a standard procedure for certificate revocation on domain ownership transfer? It seems like there really should be - even a 13 month expiry is hardly enough to prevent intentional abuse.
- tialaramex 7y ago
  "Standard" is a big ask. If this is a concern then you can proceed as follows: 1. Wait 24 hours or so after securing control over the names. 2. Use the Certificate Transparency logs to determine which certificates if any exist for names you now control and want revoked. 3. Discover the revocation process for the issuer of each cert. 4. Use each process you discovered. All of them should be willing to revoke if you can prove you now control these names. Some (Like Let's Encrypt) offer an automated way to do this, for others you may end up talking to a Customer services person or using an email ticket queue.
  - Reelin 7y ago
    Thanks for another clear explanation of process! But... the fact that there isn't some standardized automated revocation procedure that all CAs are required to support at this point seems somewhat absurd to me. At a minimum, it seems like such processes based on both proof of domain ownership and proof of private key possession should exist. Moreover, there ought to be a way to specify via DNS which CAs can issue certificates for your domain (I guess DNSSEC DANE will provide this?).

JoshTriplett 7y ago

If a certificate never expires, revocation lists have to grow without bound forever. If a certificate expires, revocation lists only have to hold revoked certificates that haven't expired.

tialaramex 7y ago

The issuer shouldn't know the private (not secret) key corresponding to the public key in the certificate anyway. In the Web PKI they're explicitly forbidden from knowing this key and good ones will react to being shown a private key by revoking any associated certificates -- that's what happened in the Trustico incident. They do know a private key for their entire CA certificate which they're using to sign things, but that's not what the expiry date in the leaf certificates they issue you is about. Nor is it intended that the lifetime of a certificate reflects the expected time to break the private key the user knows, otherwise Apple would let you have say a two year certificate if you went to P-384 certificates because they're harder to break in theory. There is obviously a threat over time that your keys leak ("Oops, the backup tapes I put in the trash have our current keys") but that's hard to assign a specific time interval to, it just means you should definitely change keys sometimes. The main thing that we're always worried about on a specific timescale is the name information. The same people control google.com today as two years ago, and likewise for my.lovely.horse but how about bobs-exhausts.example ? But the main impetus for desiring shorter lived certificates is that the certificate lifetime in practice constrains our ability to make technical changes like the SHA-1 deprecation. We'd like to make changes faster, and if you've just bought an 825 day certificate realistically our changes can't be effective in less than 825 days unless we're willing to be so disruptive your apparently valid cert ceases to work in popular browsers, which will be a hard thing to sell for merely precautionary changes.

Reelin 7y ago
I agree with your overall point and appreciate the clear explanation. However, I'd like to suggest that perhaps what you describe as "merely precautionary changes" should never occur on anything less than a ~2 year timescale anyhow. If it's urgent, go right ahead and break things. But the internet is _big_, and modifications can be _expensive_, so precautionary changes should probably occur quite slowly at this point.

zaat 7y ago

One effect of expiration dates is shorter revocation lists - if a revoked certificate was originally valid forever, the revocation list should list it since it was revoked to the end of times. Short lived certificates results in shorter CRLs. Lengthy CRLs have performance cost, they need to be downloaded and processed by clients. There is also a growing risk correlated to certificates validity length. If CRLs are unavailable to a client, the CRL server might be offline or unreachable or the client's access is maliciously blocked. The client have no knowledge of the reason and need to decide whether to trust the certificate without CRL check or not. If clients would be configured not to trust in such cases, the path to DOS is clear - block access to the CRL server and you effectively block traffic to all services of that CA. If clients are configured to trust certificates when CRLs are unavailable, which I beleive is the default on all OSs currently, blocking access to CRLs allows attacker to fool clients to trust revoked CRLs. With short living certificates, the opportunity window for such attacks is smaller.