Williams title being: `Why Adam Back keeps politicizing technical issues' I would like to comment that the reason politics are arising in discussion of communications security issues is a natural consequence of the fact that it's a damn political topic. Ignore the politics and you may implement a mandatory GAK system, or at least a GAK compliant one. Actually I also argue that there are technical security reasons why the CMR approach offers weaker security. I've gone over these reasons already in this thread, so I won't repeat them. IETF I think has a stated policy (at least this is the case for the IPSEC standardisation discussions I have been intermittently following) to not allow politics to weaken it's protocols and algorithm choices. PGP Inc introducing GAK compliance at the cost of security is a clear case where this policy should be kicking in. William Geiger <whgiii@invweb.net> writes:
In <199710110112.CAA06510@server.test.net>, on 10/10/97 at 08, Adam Back <aba@dcs.ex.ac.uk> said:
Ok Adam here is a challenge for you:
-- Explain why Corporations do not have the right to access *their* documents in whatever form they may be in.
You will note that I didn't say this. In fact I spent half of last night detailing alternate less GAK friendly ways for PGP Inc to provide corporate message snooping, the very functionality which is the motivation for their CMR. Perhas you were not reading. What I did say, and it appears to be a meme which didn't stick with you as I'm sure I raised this in a previous post replying to you is: Key functionality should be separated: in the same way that you have separate signature and encryption keys, because of the differences between appropriate backup policies, security implications, and life-times, you should have separate email receipt encryption keys and storage keys. Transient email receipt keys should not be escrowed, but for security reasons perhaps should even be securely wiped after use. As an additional security bonus: storage keys can be symmetric (where they are for your own use) which avoids the more less certain and more quickly sliding target of public key lengths. I will guess that the reason this meme doesn't suit you is that it's not the way your OS/2 pgp mail client plugins work, and therefore not yet part of your mindset. So perhaps it's not the status quo for your and some other apps to use separate storage keys for archiving and receiving encrypted mail; but there are clear security advantages to doing it this way.
-- Failing that explain how PGP 5.5 furthers the cause of GAK and PGP 2.6.x does not when I can get my network to do the same thing in a weekend and a couple of scripts using PGP 2.6.x.
There is are some clear differences: 1. You can visually see multiple crypto recipients in most PGP enabled MUAs, as they usually correspond to email CC fields. 2. PGP Inc is attempting to weakly enforce this special purpose message snooping recipient embedded into the key certificate. 3. PGP Inc even has (less clear on details here) I think from Jon Callas first post: pgp 5.5 client which enforces inclusion on sent mail as controlled by a remote company message snooping czar & enforced inclusion on received mail by the SMTP policy enforcer. 4. There is a difference between what you or I may knock up in scripts, and what PGP Inc attempts to persuade the IETF include as conformancy requirements, and what PGP does implement ahead of the standardisation process. 5. The IETF process should be accepting proposed designs and deciding on the best ones, which PGP Inc, and the other suppliers would then go and implement. As it is now, as William Allen Simpson just pointed out, PGP Inc is cruising ahead implementing, and deploying things without bothering with the OpenPGP process. Your point about using normal multiple recipient to provide snooping is a good one. It would be a much less GAK friendly solution for PGP Inc to encrypt to a second recipient without any message snooping flags encoded into the PGP standard. That way email clients won't reply to this second recipient, and users won't have an automated snooping feature embeded in their PGP for personal privacy, or competitor re-write of the same compliant OpenPGP app, for someone else's benefit (recipient company, or government). To snoop received email, it provides similar amounts of snooping enforcement if the recipient's PGP 5.5 for business client when the user decrypts re-encrypts to a storage key that the company does have escrowed, or where there is a second crypto recipient in the storage. (Talking mail folders here.)
-- Failing that explain why there were no great outcries that PGP 2.6.x is GAKware???
See above. The objectionable new feature in PGP5.5 (and apparently pgp5.0 too without our realisation to this point) is enforcement in senders clients to support message snooping, in a form which can easily be used to interoperate with GAK, and thereby prepares everyones OpenPGP compliant email client to enforce GAK against them. At the very most the maximum acknowledgement that it seems reasonable to me for OpenPGP to have of the GAK compliancy feature is to flag this key and allow the user to send to this recipient at their option. In addition I am arguing that PGP Inc are doing the Internet community a major disservice by choosing to implement message snooping in this way. Much better, less controversial, and more secure to do the snooping in the pgp5.5 client after decryption. That doesn't need to involve changes to the message spec. PGP Inc's SMTP policy enforcer could then be changed in functionality to stripping off the company snooping crypto recipient field before it leaves the LAN for security reasons.
Now if you agree that Corporations *do* have a right to access their documents but you disagree with the technical aspects of how PGP 5.5 achieves this then drop the fearmongering and spell out how you think this can be better achieved.
I already did this half a dozen times. I'm not fear mongering, I'm attempting to point out the dangers of including GAK compliancy. And to point out the opportunity to make PGP non-GAK compliant, and thereby frustrate mandatory GAK proponents. PGP is trying to discard this opportunity, when there are clear alternate methods which can be argued are more secure, better meet PGP's Jon Callas's stated user requirements, don't support GAK, and don't require modifications to the standard. 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`