An acqaintance of mine received an evaluation copy of the new PGP For Business Security 5.5 suite, and I was able to generate some test keys to play with the message recovery features. I've uploaded them to the cert servers so folks with the 5.0 client software can experiment with them for interoperability, etc. The recovery key is "Little Brother <snoop@localhost>", fingerprint 26A5 667A 97D4 7018 1B18 2B15 D631 4776 B670 E1D0; a test user whose incoming and outgoing mail is forced to include the recovery key is "CMR User <snooped@localhost>, fingerprint EC79 A170 8BAE 60A1 3CAC C517 34A4 6056 EE42 30E3. Both keys are 768-bit DH keys, as I don't expect that anyone will use them for anything other than testing. Installation of the package involves multiple steps - there's an "administrator install package" (my term, not theirs), which installs a version 5.5 of PGP, including the PGPTools, PGPKeys and PGPTray apps, as well as a PGPAdmin program. To implement CMR, the ordinary PGPKeys app is used to create an otherwise ordinary PGP key pair; the administrator then runs the PGPAdmin app, which asks questions about security/recovery policy. The admin can force incoming messages to use a recovery key, can force outgoing messages to use a recovery key, can enable/disable conventional encryption, can enable/disable key generation (and RSA key generation), can force a key to be trusted and to act as a trusted meta-introducer. The admin can also force the user to use a strong passphrase. (PGP 5.5 includes a neat passphrase-strength-meter which changes depending on the length and apparent alphabet-space used in the passphrase for user keys.) Finally, the admin can force the user to sign/trust a designated Corporate Signing Key. After the administrator sets those policy choices, the PGPAdmin tool can be used to generate a customized installer application for distribution to users. That installer creates a local copy of PGP, which will enforce the policy choices made by the administrator. The user is warned upon key generation that a message recovery key will be used (if the app is thus configured) and that the behavior isn't optional. The recovery key ID is displayed but not modifiable. The user interface for 5.5 is much improved over that in 5.0, which was a big improvement over the command line. There's an indicator (initially preferenced to OFF, along with other information) in the PGPKeys application which marks CMR'd keys with a red button; the interface between PGPKeys and the key server is much improved. It's now possible to mark & retrieve many unknown keys, then approve adding them to the local keyring in one step, instead of approving the addition of each additional key. The icons & screen design have been updated and are now more colorful and easier to decipher. When a user with CMR-only client software encrypts data, the ID of the recovery key appears in the "encrypt to" box, and cannot be dragged out. A CMR-client will (apparently) still do conventional encryption with no recovery key if the admin allows this. -- Greg Broiles | US crypto export control policy in a nutshell: gbroiles@netbox.com | Export jobs, not crypto. http://www.io.com/~gbroiles | http://www.parrhesia.com