On Tue 2018-04-17 09:44:24 +0200, Thomas Goirand wrote: > Yes, though it should be an exception, the general use case is that it > should not happen: if you publish the new subkeys early enough, new > messages will be using the new subkey.
I don't think it matters how early you publish the new subkey -- as soon as you publish it, some messages will start coming in with the new subkey, while some other messages will arrive encrypted to the old subkey. so there's pretty much always a window where messages arrive addressed to both. >> The most important security added by rotating your >> decryption-capable subkey comes in when you can actually *delete* the >> private part of the subkey. When you can do that, then anyone who has >> captured encrypted messages to that subkey can no longer force the >> secret key out of you to decrypt the message. > > Oh indeed! > > Then probably we should just accept the fact that, when someone encrypts > a message with the old key, we can't read it, and we have to ask for a > new message to be sent. I don't think that's a big problem. If someone encrypts a message to the old subkey while the old subkey is not yet expired, that's totally reasonable. asking them to re-send/re-encrypt the message is a terrible user experience. It's one of the thousand papercuts that keep people from embracing encrypted e-mail. That's not a great tradeoff. Te takeaway that i'm getting from this thread is that there isn't anyone using smartcards for decryption-capable subkeys that rotates those subkeys. That's a useful observation, if a bit disappointing. --dkg