Great, now you need to constantly go to some site like caniuse.com to see what % of browsers thinks your certificate is valid.
In the original conception of X.509, it was supposed to be an enterprise's system administrator (e.g. a university's IT department) that would define the set of root CAs that the enterprise's computers would trust. So there'd be literally no way to know whether a given user device would trust your certificate. That was supposed to be a choice that is up to them, not something you can pre-guarantee by making deals with third parties.
That’s what is happening now. Except for common sense, nothing stops a browser from trusting a certificate with an expiration date in the past.
The expiration date more is a statement from the issuer “I wouldn’t trust this after this timestamp”.
Having said that, I think Apple should say “our OSes will stop trusting certificates issued over two years ago” instead of ”our OSes will stop trusting certificates that expire in over two years”
If they did that, one could still use certificates with longer expiration periods, allowing other parties to cache them for longer periods.
Now they force everybody to follow them, so that, if this change breaks sites on iOS, it also breaks sites everywhere else.
This is designed to fix the fact that revocation is utterly broken.
You really don't want a situation where webpages may work or not work based on some completely unclear criteria.
- Safari
- max 398 days
today. Tomorrow they may change to be 397 days, or 39.8 days, or "until the next iPhone is released".
The 398 days isn‘t something they came up right before they presented it. It‘s already 3 years old...
The de facto standard will be that you will need to accommodate the least tolerant user agent if you want your certs to work for all browsers.
If I'm understanding correctly, the GP is saying browsers should be making decisions based on a much wider variety of criteria (for example, who issued the cert, how popular is the website using the cert, etc), which would be much more difficult to troubleshoot.
And yes, the de facto standard is that for the general purpose web you can't sell certificates based just on, for example, getting an OK from Microsoft (whose trust stores includes a tonne of governments and government agencies whose inclusion a cynic might assume is not coincidental to those governments agreeing to purchase Microsoft's products...) because those certificates don't work on an iPhone or in Firefox or...
The relationship that is symbolised by the CA/Browser Forum has always been asymmetrical like this, it was this way before the CA/B Forum was created, and if the two groups aren't able to reach common ground the CA/B will just gradually go away.
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?
2. Recurring revenue models for CAs.
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.
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.
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.
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.
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?).
You can use CAA to tell CAs whether they're authorised to issue for names in your domain, and since CAA is a DNS resource you can secure it with DNSSEC. But CAA isn't retrospective, it won't magically revoke certificates which already exist, although it could prevent issuance based on stale authorisations because it's supposed to be checked live.
Using DANE here would be pretty fraught even if it was widely deployed which is far from the truth.
If a certificate expires, revocation lists only have to hold revoked certificates that haven't expired.
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.
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.
Well of course they should, that's why it is right there, called "not before"
> The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.
Well, that exaclty is the case. Most clients decided to honor the recommended expiration date, and Apple just announced they won't.