If we take the design goal of designing a commercial data recovery system which is not GAK compliant, we can most succinctly state this design goal as the task of ensuring that: - at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient with out also obtaining data on the recipient and/or senders disks I think we can distill the design principles required to meet the design goal of a non-GAK compliant Corporate Data Recovery (CDR) down to ensuring that: 1. no keys used to secure communications in any part of the system are a-priori escrowed with third parties 2. second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender 3. communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible Included in 2) is the principle of not re-transmitting over communication channels keys or data re-encrypted to third parties after receipt -- that is just structuring -- and violates design principle 2. With these three principles you still have lots of flexibility because you can escrow storage keys, do secret splitting of storage keys, and store keys encrypted to second storage accessors on the local disk for stored data recovery purposes. As an additional bonus, principle 3 adds extra security against attackers gaining access to encrypted traffic after the fact -- the recipient no longer has the key -- this is a form of forward secrecy. Systems designed to the CDR design principles are of significantly less use to GAKkers than PGP Inc's GAK compliant Commercial Message Recovery (CMR) design. The CDR design significantly hinders the take up of GAK if widely deployed. Design principle 3 -- forward secrecy -- is inherently hostile to GAKkers, and is the strongest statement you can make against GAK: you are purposelly _destroying_ communications keys at the earliest possible moment to ensure that GAKkers can not obtain the keys by legal and extra-legal coercion, black mail, and rubber hose cryptanalysis. The whole system translates into the Feds having to come and physically take your disk to obtain information about you, which is much better than GACK, and not what the GAKkers are interested in at this point. The GAKkers would like to install themselves, and coerce companies into installing for them (via GAKker/USG/NSA/NIST organised efforts such as the 56 bit export permit for companies installing key escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)). I fear that PGP Inc's CMR proposal inadvertently meets most of the NIST/NSA specified KRAP requirements. What the GACKers want is systems where they can perform routine key word scanning and fishing expeditions into your communications from the comfort of their offices, without your knowledge. This is push button Orwellian government snooping. Within the constraints imposed by the CDR design principles, there is plenty enough flexibility to acheive the commercial data recovery functionality to similarly weak levels of enforcability as achieved by the CMR design. Weak levels of enforceability are appropriate because there are other exceedingly easy bypass routes: super-encryption, and walking out of the office with a DAT tape. I would like to organise a collaborative effort to write a white paper discussing how to implement various functionalities using the CDR design principle. Then I would like to see discussion of which set of these functionalities which best acheive the user requirement for company data recovery. Lastly I would like to see a collaborative development effort to provide a example implementation of a CDR system which can be used as a discussion point for the OpenPGP standardisation process. I suppose the best place to discuss this process is the IETF forum for discussion of the OpenPGP standard, the OpenPGP mailing list (subscribe by sending message body "subscribe ietf-open-pgp" to "majordomo@imc.org"). I have already had people express in email to me their interest in doing this. Those people can speak up if they want to. Technical input is sought from people opposed to GAK compliant software, and from PGP Inc, and others defending PGP's GAK compliant CMR proposal. 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`