* Once you think about this more though, you realise that it does make sense and that it just doesn't seem logical upon first thought. In order to make this cha

* Once you think about this more though, you realise that it does make sense and that it just doesn't seem logical upon first thought. In order to make this change and it actually have an effect on the client, you need to have access to that client with administrative privileges to change the root store. If your concern is that an attacker might do something like this, well, I'd suggest you have far bigger issues to concern yourself with given that the attacker has admin/root and is on your device!* Yes, it's true that not just anyone can modify your local trust store (and if someone does, yes, you've likely got bigger issues). When I started to "think about this more though", my first thoughts were more along the lines of ... "What assertions have the CAs made -- whether implicitly or explicitly -- regarding their security measures / practices (WRT private key material, of course) once 'NotAfter' has passed?" ... and similarly ... "What obligations do the CAs have -- either morally, ethically, contractually, and/or in accordance with the Baseline Requirements -- to continue to protect the 'C-I-A' of the private key material after 'NotAfter'?" I'm fairly familiar with the BR's, having spent more time reading through (portions of) them than I'd have preferred -- and I keep a hard copy here in one of my desk drawers -- I'll happily admit that don't know the answers off the top of my head. To be clear, I trust [0] that no ("responsible") CA would ever do something like publicly share the private key used to sign a "trusted" root certificate -- or even an intermediate / subordinate, for that matter -- regardless of how much time has passed since 'NotAfter' ... However, when a CA generates such a certificate (and/or the private key, for the pedants), requests that it be included in one or more of the various root programs, and agrees to the conditions / requirements of such programs -- including, obviously, the BR's -- they're promising that they will keep those certificates (that is, again, the key material) secure. This isn't an "eternal promise", though, and the 'NotAfter' date that they include in the certificate is how they tell everyone how long that promise is valid for -- that is, it is, literally, an expiration date [1]. Once that expiration date arrives, though, their obligation has been fulfilled. I may very well be forgetting some relevant provisions of the BR's at the moment [2] but once the CA's promise has expired, is it appropriate to expect them to continue keeping their promises (i.e., keep trusting the certificate) if they haven't asserted that they will continue to keep those promises (by renewing the certificates)? [3] -- [0]: Although "expect" (perhaps just "hope") is probably a more fitting word choice here. [1]: Yes, they can extend -- "renew" -- that promise later, if they so choose. [2]: And this is the point at which I'd typically go review them to clarify the matter (just for myself) but this entire comment is mostly rhetorical (a "thought exercise", if you will). [3]: Personally, I think that "trusted" root certificates should automatically become "untrusted" (and, of course, get flagged as such) immediately upon expiration but that's a whole 'nother argument involving operating system vendors, browser makers, and many other parties. Luckily, the operating system and software I use allows me to be the ultimate authority over matters such as these!