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 ", 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
, 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
