Hal Finney, now working for PGP
PGP now offers an extensible signature format. This allows key signatures, both self-signatures by a key on itself, and ordinary key signatures by keys on other keys, to do more than before. The extensions are in the form of subpackets within the signature packet. Various subpackets have been defined, and Open-PGP would be an excellent forum to propose and design new subpacket types and corresponding data formats.
OK, that means the correct technical term for my discussion is an argument over the GAK compliancy subpacket type.
Some of the subpackets are modifiers of ordinary userid-binding signatures. These allow signatures to have expiration dates; to be marked as non- exportable (so that the signatures are only for your own use on the keyring);
I really like this non-exportable signature option. It is highly useful. I have a couple of keys on my key ring with signatures on them that I have mentally flagged as non-exportable. This is because they are signatures by the True Name of nyms I happen to know the True Name of and are intended to allow me to transfer the trust to that Nym, but the Nym is trusting me not to make public this signature. It would be really kind of neat to extend this functionality so that I _couldn't_ export the key by making the certifcate a non-transferable signature, or a designated verifier signature.
And here there is the new corporate message recovery key (CMRK) subpacket.
This is the controversial object. I have been arguing in a couple of earlier posts today that this design is a bad idea from a security perspective, and from the point of view that it is a form of GAK compliancy when coupled with PGP's SMTP policy enforcer. The reason I say this is that if we get to the situation where many businesses are using PGP 5.5 + PGP policy enforcer, the clients "choice" to not encrypt to the message snooping second crypto recipient in the CMRK subpacket will have little practical meaning. The user will be forced to comply or be unable to send messages which don't bounce. A better place to do corporate snooping, and to avoid the extra security risk of sending messages over the internet encrypted to two rather than one long term encryption keys, is to snoop the plaintext after it has been decrypted in the PGP 5.5 mail client. Also, the message snooping functionality is reading between the lines; Jon's post no where mentioned this as a user requirement. What he said was that corporates had a need to recover encrypted email messages stored in encrypted mail folders. If this is truly the case, the functionality is even easier to achieve, just encrypt the mail folder to a company escrowed storage key after decryption. Easy to do, and more secure. Same flexibility in reflecting the internal structure of the company's trust and risk management in the storage key escrow architecture.
The CMRK subpacket allows a key to request that when a message is encrypted to it, the message should also be encrypted to a specified additional key. The subpacket includes a flag byte which is designed to allow the key to give information about the circumstances under which this should be done. Only two values are presently defined, one specifying an optional request, and the other meaning that the message will not be read by the recipient if the additional encryption hasn't been done.
If PGP is going to forge ahead and try for this flawed message snooping architecture anyway, I would urge you personally to at least press upon them to remove the flag meaning that a message will not be received without the use of the message snooping key, and to remove the functionality preventing delivery in the SMTP policy enforcer.
I won't address the controversy about this feature, as that is being thoroughly discussed in other forums. Let me make two points, though:
OK. The controversy has technical basis too -- and seems to be starting to be discussed in this forum also. There is also a question of how this design interacts with the IETF policy of not allowing political issues to weaken protocol designs to discuss.
We would like to move towards a mechanism to allow more power for keys to make assertions. Matt Blaze's (still vaporware?) PolicyMaker project showed how powerful such a general mechanism could be. SPKI is also working along these lines, defining a certificate format which allows keys to make very general classes of assertions.
I've read Matt's PolicyMaker paper. I can see the attraction of moving towards these generalisedl trust statement syntaxes. I would be nice to see the topic of the recipient refusing email based on policies relating to third party access to messages in transit being addressed in the standard when and if PGP gets to that stage. There are some nice uses for some types of recipient refusal. Ecash payment for message processing, or my less $ oriented hashcash proposal also. (The types of problem that can arise with real ecash payment for receipt, which hashcash avoids is that if applied to discussion forums, it can bias the forums to allowing through more of what rich people have to say. A similar argument perhaps applies to email following up to comments made in public forums, you can only reply to someone if you have the money. Busy people may set very high payment rates.)
The CMRK is one such type of assertion: "please cc to key X anything encrypted for me". The key is requesting that the specified other key by an additional recipient on encryption.
I can see problems with this type of assertion. I hope when the time comes that a way to define a convetion or set of rules which disallows this as part of the standard.
If we move to a sufficiently powerful language to allow keys to make useful assertions, it seems to me that we will probably inherently allow keys to make assertions of a type which some people may regard as politically unacceptable, like this one. But to artificially constrain the language so that it can only say things which are politically correct will make a an already-difficult design task into an intractable one, I'm afraid.
We'll see when we get to it. In the mean time, PolicyMaker & look-alikes are vapourware.
Ultimately, a fully general and flexible system of key assertions will allow keys to say stupid things as well as smart ones. I believe that the power gained from having such a language gives advantages which outweigh the problems of misuse. (Note the similarities to the debate over the PICS labelling technology, which some people oppose because it could be misused.)
It's similar to PICs in that third party rating services are fine (for example consumer product evaluations in various magazines), but centrally controlled ones are objectionable to many of us.
Secondly, with this type of assertion, as with others such as the preferred algorithm packet, it is inherently in the sender's (encryptor's) power to ignore it if he chooses. You can request that I not use triple-DES, but I could still send you a message encrypted with that algorithm. You would then have the choice to reject it or accept it. This is a point which I owe to Phil Zimmermann.
The problem with this point, which you say is PRZ's, is that it falls down for interoperability reasons when the system is widely deployed. Exactly how much "choice" do you have when 80% of businesses will bounce your mail if you don't comply. How much "choice" do you have a few years later when 95% of individuals and companies are using the same system, and the government is holding the master snooping keys. [1] The long term likely value of this choice is rather low, so the assertion that it leaves you empowered is a weak assertion. You would paradoxically in this case be much more empowered if the recipient did the escrowing silently after receipt by decrypting and storing his mail folder with an escrowed storage key. Of course it would be nice if this policy was advised in the public key also, to at least warn you, in case you mistook the persons email address as a private account. (Some ISPs have names which look similar to some companies names,... domain names ending in .com, if you are not familiar with the company name).
Likewise in PGP 5.0 the user can override the CMRK request even in its strongest form (although not in 5.5, because that is intended for business-to-business communications).
I submit for the above reasons that this overriding feature will in the long term me fairly meaningless. What is the practical individual empowerment transferred in being able to override something in the sure knowledge that it will thereby be bounced and not delivered.
Therefore, I very much agree with Jon Callas that an implementation which (perhaps optionally) allows overriding the requests which a key makes in its self-signatures should still be considered compliant. That is consistent with the nature of the sender's power to create the message.
I strongly disagree for reasons stated in paragraph [1] above.
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