On 5/11/2010 8:08 PM, Daniel Kahn Gillmor wrote: > On 05/11/2010 07:42 PM, Joke de Buhr wrote: >> The encrypt-to-all-encryption-capable-subkeys ensures that the owner of the >> primary key will always be able to decrypt the message no matter what (not- >> revoke) encryption key secrets he can access at the moment. > > yup, i think this is a good argument for your proposed behavior. what i > haven't seen yet (haven't thought through yet) is what the > counter-arguments might be. >
I think the semantics and correct behavior become unclear when one of the keys is revoked. - Alice has two encryption keys. - Bob sends to both keys. - Alice revokes one key. - Bob doesn't refresh his keys. Continues sending to both keys. - The unrevoked key decrypts things just fine. If Alice has one key and revokes it, she'll get a warning that Bob is still sending to the revoked key, and can take corrective action. If Alice has two keys and revokes one, should it behave any differently than if another revoked key is used? Right now when I decrypt something, gpg doesn't bother to check to see if other users are revoked (according to my keyring.) gpg is still matching one good key with one good asymmetrically encrypted symmetric key packet. So now Alice doesn't even realize that Bob is still sending sensitive info on a potentially compromised key. You might be able to put a weird exception where gpg checks to see if any of your private keys that are revoked are one of the keys that gpg has encrypted to, but that would behave completely differently than having a revoked key from random user X on the keyring. And if you did, I'm not sure how applications like Enigmail would end up handling the special case.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
