Encryption to key with multiple subkeys

[Grant Olson]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100511/06f4f52f/attachment.pgp>