Anonymous writes:

Remind me again:

Why was it OK when the SENDER could choose to encrypt to an additional key, but it's a threat to the free world if the RECEIVER is allowed to request the same thing?

It's a threat to the free world if the RECEIVER is allowed to request the same thing when PGP Inc also goes ahead and implements an enforcer to bounce mail failing to meet this `request'. This is not a `request', this is an `insistance'. This is a ready to roll system which could be used as-is to implement GAK. It is also potentially dangerous even without the SMTP policy enforcer because if this functionality (CMR public key extension) is part of the OpenPGP standard, then conformant OpenPGP implementations are pre GAK enabled -- when GAK comes in, they know how to send to CMR keys, and the enforcement can be added later. Notice also that using comparisons with pgp2.x multiple recipient functionality to deflect criticism is a complete red herring: pgp2.x multiple recipients do not request copies mail to keys to be sent to other keys. All crypto recipients correspond 1-1 to message recipients, and in most cases there is only one message recipient (and therefore only 1 crypto recipient). This is better security, and it can't be used for GAK anywhere near as easily as CMR. And yes turning encrypt-to-self on violates 1-1 correspondence with message recipients, but encrypt-to-self is also a security flaw to use this feature. I rant about the security risk of encrypt-to-self periodically, as a search of the archives would show. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`