From Bill Stewart's report, given the apparent amount of effort PGP have put into their CMR based enforcement policy functionality, I
The 3 main GAK-hostile design principles are also independently good security principles in protecting communications traffic. There are ways to acheive data recovery functionality without CMR. I think I have demonstrated amply what these methods are, and have given a design methodology for designing such systems. PGPers are just not interested to hear. predict they won't remove CMR whatever we, or Schneier, or anyone else says or proves about more secure less GAK-friendly ways of implementing corporate data recovery. I also suspect they won't listen to Tim's earlier argument that they do nothing about recovery of messages rather than implement GAK. This quote should give us clue as to why they will continue with CMR: "we're a real company with accountants" So they are not willing to follow through the anti-GAK design process where this could hinder bottom lines. Similar arguments would presumably present them with "no choice" but to fulfill the order for 100,000 GAK compliant units from the government terrorizing the freedom fighters PRZ likes to tell us about who are already using PGP GAK compliant software: pgp5.0. Tim May <tcmay@got.net> writes:
let me throw out some examples where CMR introduces flaws into a security system.
[snip]
I think Tim's points are very valid. CMR functionality if put into the OpenPGP standard _will_ be used by PGP competitors to implement message screening and snooping by company security guards etc. It will I am almost positive in due course be used to field such software in countries with poor civil rights records. Maybe PGP is not fielding systems they are "advising" their clients to use for GAK, or for message screening, but this is what is going to happen. Their good advice isn't as much comfort as an OpenPGP standard which is as hostile to this practice as possible, and a pgp data recovery implementation which is also hostile to this. PGP do not want to hear this. It will cost development time. The many people who have expressed to me off list that PGP has sold out, are I think correct.
Which means we're back to square one. So why does PGP, Inc. bother?
And why should OpenPGP squander efforts worrying about this?
I think that except for carefully worded statements by PGP Inc employees all those who have spoken on the topic in the OpenPGP forum have agreed. The CMR field should not go in OpenPGP. This means that the PGP SMTP policy enforcer will not meet the OpenPGP standard: it will bounce mail from compliant implementations which ignore the CMR field. I think this means that the person who suggested this: OpenPGP is unlikely to continue to be supported by PGP Inc to me in email made a good prediction. What can we do about this situation? Well we could build systems which hack around the CMR system. Easy enough: just put dud "recovery" info inside. We still have deployment problems. 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`