Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com>:
A program receiving a CMRK can do several things
0) Be confused and crash when receiving public key records
containing CMRKs :-)
1) Reject public key records containing CMRKs and complain to the user
2) Ignore the CMRK and process the main key, though you need to record
the CMRK in the public key database since it's part of the signatures.
3) Ask the user whether to encrypt a copy to the CMRK, if there's a user
4) Ask the user, who's not there to respond to a dialog box, and hang
5) Cooperate with the request, doing something appropriate if you
need to fetch the key matching the CMRK KeyID.
6) Implement some totally different functionality using that field
7) Obey Blindly
There is one more option. For every public key encryption, the sender
also has the option of sending garbage (in the case of RSA, a random
number in the interval 1 .. N_key - 1; in the case of ElGamal, two
random numbers in the interval 1 .. p_key - 1) instead of real data.
Only with the appropriate private key is it possible to find out that
the "encrypted data" does not make any sense.
This feature is (AFAIK) not available in any version of PGP, up so
far. But I always thought the user should have the possibility to
1. add recipients to public key encrypted messages (provided that he
can decrypt the message himself),
2. add "fake recipients" in the sense explained above,
3. delete recipients.
Usually, these features would have been pretty useless (although this
obviously changed with the advent of PGP's e-mail filtering gateway).
However, their existence would educate every PGP user that
* PGP's message claiming that "This message can only be read by <list
of user keys>" does not really guarantee that all those users are
in fact able to decrypt the message, and
* that it also does not guarantee that the original sender chose the
same list of recipients that is present in the received message.
Note that options 2. and 3. above do not require the posession of a
private key; i.e., they can be done by an attacker while the message
is in transit. I am sure that many PGP users assume that, when PGP
informs them that a message "can only be read by ...", the sender is
responsible for the decision who can (apparently) read the message --
while in fact there is no authentication for that. Having features 1.,
2. and 3. implemented in PGP could help to prevent that unjustified
assumption.
Bodo M"oller
<Bodo_Moeller(_at_)public(_dot_)uni-hamburg(_dot_)de>