It's interesting that this came from Apple though, and seemingly (from memory and a brief review of the list archives) without much prior discussion. The CA/B Forum is an inherently asymmetrical body, its rules recognise this, and there is always the threat that the relationship it embodies could break down or cease to be relevant.
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 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.