On 01/06/2015 04:23 PM, Patrick Brunschwig wrote: > The point here is (I know, it's not well enough documented) that I > decided to ignore per-recipient rules for BCC recipient; and we also > decided to exclude BCC recipients from some of the logic for > enabling/disabling encryption. Unfortunately I don't recall the reasons.
One possible reason could be: * under "convenient encryption", when all to: and cc: addresses have keys, adding a bcc: address that does not have a key causes encryption to be disabled. However, in the same circumstance, adding that address to: or cc: would have the same effect, so i don't think this is a particularly good reason. I think the right thing to do is to treat Bcc: recipients the same as the To: or Cc: recipients, whether that's with "convenient" settings or per-address rules. I believe this is a closer match to most users' expectations of what should happen. ------ More nuanced details related to OpenPGP, encryption, and BCC (which i think enigmail already gets right, but i think are worth noting in this context): The one drawback to this plan is that the OpenPGP packet format makes it clear to which keys a message has been encrypted, in the keyID field of each PKESK packet: https://tools.ietf.org/html/rfc4880#section-5.1 this potentially makes the Bcc not very blind, because the recipient can enumerate PKESKs. The fix for this is to always send the Bcc address to gpg as --hidden-recipient, which enigmail does. (this sets the keyID field to all-zeros for that PKESK) So this still leaks some information that *someone* else has gotten a copy, but not who, which i think is acceptable. Note, though, that if the hidden recipient PKESK is placed ahead of the regular non-hidden PKESK, then some (all?) versions of GnuPG will ask the (non-bcc) recipients to unlock all their private keys to try to decrypt the hidden PKESK before processing the PKESK that belongs to them. This is pretty annoying for people who have more than one secret key available, so placing all hidden PKESKs *after* the non-hidden PKESKs should reduce the annoyance. I think that enigmail already does this properly as well, assuming that GnuPG's emitted PKESKs match the order of the --recipient and --hidden-recipient arguments. --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
