Re: What this WG is doing

[Bill Stewart <stewarts@xxxxxxxxxxxxx>]

At 01:03 PM 10/29/1997 GMT, Lutz Donnerhacke wrote:
>* Ian Grigg wrote:
>>In the current understanding of the community, the only plausible
>>alternative is to simply omit all mention of the CMRK subpacket from the
>>standard.
>
>No. It is possible to document is and point out the security consequences in
>chapter 'Security Considerations'.
>It is only undefined, who edit the draft to move forward.

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

A program generating a public key record can do several things
8) Don't generate a CMRK field
9) Generate a CMRK field if asked to, either for eavesdropping
	or as a mechanism for implementing group keys.
10) Use the CMRK field for something else functional
11) Use the CMRK field to store bogus records to trap PGP Business 5.5 users :-)

I'd recommend strongly against 0, 4, and 7, just in general, and 
weakly against 1 and 11.  
I'd say 3, 5, and 9 are permissible actions, but shouldn't be in the spec
except perhaps under "Security Conditions" or some similar appendix.  
2 and 8 are at least SHOULD, and 6 and 10 probably SHOULD NOT BUT MAY.
				Thanks! 
					Bill
Bill Stewart, stewarts@xxxxxxxxxxxxx
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639