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(_at_)ix(_dot_)netcom(_dot_)com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639