A certificate is a secret. The longer you have a secret the more likely it is to be learned by others. Expiry is about risk mitigation, the shorter the expiry the smaller the risk.

Here risk is exposure of the key or the certificate being compromised. If it takes X time to break a certificate then an attacker will know your secret for expiry - X. We’re being hopeful that 13 months is unattractive to attackers given the current values of X even at the nation state level, and with cryptography we always have to look into the future not what’s capable today. There’s also a “herd immunity” thing going on if we all have shorter expiry as there are no easier targets and the attacker has to become much more focused.

IMHO there’s also benefits in rotation your cert more often. If you do it once every three years it’s more likely the folks who did it last time aren’t with your company or just plane forgot what they did. I think 13 months is still too long, I’d prefer every quarter because it forces the investment is a control system to facilitate rather than half-automated manual tasks. But that’s not what this proposal from Apple ios about.

The original ballot was 3 yr -> 13 months with ballot 185 which did not pass. Text reason[0]:

> The validity period of certificates represents the single greatest impediment towards improving the security of the Web PKI. This is because it sets the upper-bound on when legacy behaviours may be safely deprecated, while setting a practical lower-bound for how long hacks and workarounds need to be carried around by clients.

Another reason I see is that your HTTPS certificates aren't invalidated when you don't renew a domain name, so an attacker could potentially MITM HTTPS if they previously owned the domain and had a valid long-lived certificate. The browsers all want automation and 90-day certificates, but that's the polar opposite of what CAs want.

0: https://cabforum.org/pipermail/public/2017-January/009373.ht...