Encryption to key with multiple subkeys

[Joke de Buhr]

On Wednesday 12 May 2010 02:49:43 Grant Olson wrote:
> 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.

Here are some tests how gnupg currently handles revoked subkeys. As you can 
see programs like Enigmail would notice if someone is still sending to a 
revoked subkey. If programs now recognize mails are being encrypted to revoked 
subkeys they would notice with a encrypt-to-all-not-revoked-encryption-subkeys 
behavior.


Alice has a primary key with two encryption subkeys:

  pub  4096R/637AD7FA  created: 2010-05-12  expires: never       usage: C
                       trust: ultimate      validity: ultimate
  sub  4096R/97E46ACF  created: 2010-05-12  revoked: 2010-05-12  usage: E
  sub  4096R/5855A984  created: 2010-05-12  revoked: 2010-05-12  usage: E
  [ultimate] (1). Goo Gle <goo at gle.com>


Three messages were send to Alice (last would be encrypt-to-all):
  10.asc encrypted to subkey 97E46ACF
  01.asc encrypted to subkey 5855A984
  11.asc encrypted to subkeys 97E46ACF 5855A984


Alice decrypts the message if no key is revoked:

  gpg2 --decrypt -o /dev/null < 10.asc
    gpg: encrypted with 4096-bit RSA key, ID 97E46ACF, created 2010-05-12
        "Goo Gle <goo at gle.com>"

  gpg2 --decrypt -o /dev/null < 01.asc
    gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
        "Goo Gle <goo at gle.com>"

  gpg2 --decrypt -o /dev/null < 11.asc
    gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
        "Goo Gle <goo at gle.com>"
    gpg: encrypted with 4096-bit RSA key, ID 97E46ACF, created 2010-05-12
        "Goo Gle <goo at gle.com>"

Alice revokes a subkey (first or last) (example: 97E46ACF):

  gpg2 --decrypt -o /dev/null < 11.asc
    gpg: NOTE: key has been revoked
    gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
        "Goo Gle <goo at gle.com>"
    gpg: encrypted with 4096-bit RSA key, ID 97E46ACF, created 2010-05-12
        "Goo Gle <goo at gle.com>"

Gnupg informs Alice the message has been encrypted with a revoked key if Bob 
didn't refresh his keyring and his gnupg continues to do a encrypt-to-all. She 
could inform Bob to refresh his keyring. The same goes for other combinations 
of key revocation. 

If Alice revoked her last key (5855A984) and Bob's (unrefreshed) gnupg would 
encrypt a message to the last key as it currently does it would look like 
this:

  gpg2 --decrypt -o /dev/null < 01.asc
    gpg: NOTE: key has been revoked
    gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
        "Goo Gle <goo at gle.com>"

There is no different on Alice side if gnupg would do a encrypt-to-all-not-
revoked-encryption-subkeys.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 706 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100512/bdbc971d/attachment.pgp>