[detaro]

That's primarily an argument to rotate keys quicker - computers don't care that they have to remember new passwords all the time (which is the main argument against password change requirements: it encourages bad practices from users), so you can do schemes like OAuth2's Refresh Tokens. (and even slow-ish rotation helps with keys forgotten in random places)

[brokenwren]

I completely agree. But even at 15 or 30 days, it's too long. The only way to protect a key would be to rotate it every day or every hour.

[detaro]

It's steps. E.g. if it's every 15 days, it at least pushes you to the point of automating it (HOPEFULLY) and the app managing it internally - that already helps against stupid shit like "someone put it in code/pushed a config file/... to a repo that later got compromised". Similarly, every X months is still a gain over keys sticking around many years. But yes, at the same time, if you get to have a reliable automated flow there is little reason to not run it with higher frequency.

[brokenwren]

So, do you know of anyone that has written this type of thing up? I'd love to have some fodder when having these types of discussions. :)

[detaro]

Hm, not specifically. OAuth2 specifications and documentation sort of address the motivation for Refresh Tokens at least (and are widely written about in blog posts etc) - and I think the security recommendations documents now strongly push for Refresh Tokens. For the benefit of automated refresh one could also pull the Let's Encrypt arguments as "similar enough" and widely recognized as good practice.