Possible cl.cam.ac.uk PGP recommendations

Here is a brain dump of some thoughts which might some date become departmental recommendations.

Keys should be generated from within Help in exmh

exmh has code to make it (too ?) easy for users to set up PGP keys. Rather than re-inventing the wheel, effort will be put in to get this to follow localy recommendations. Use `Help... -> Pgp Setup -> Make Key' to generate the key, entering strings similar to the suggestions in the `PGP Setup' window.

As an example, the responses might be

  1. Piete Brooks <Piete Brooks@cl.cam.ac.uk>
  2. Secret Pass Phrase
  3. Secret Pass Phrase
  4. (key presses until it says `0 * -Enough, thank you.')
  5. Y
  6. Secret Pass Phrase
  7. Secret Pass Phrase
  8. Y
  9. Piete Brooks <pb@cl.cam.ac.uk>
  10. N
  11. N
  12. Secret Pass Phrase
  13. Y
  14. Piete Brooks <pb22@cam.ac.uk>
  15. N
  16. N
  17. Y
  18. Secret Pass Phrase
You should now be able to sign and/or encrypt messages using `Comp -> PGP... -> PGP/MIME encrypt and sign'.
If you want to include the info in your .plan, then add something like 
PGP: KeyID 1024/4960EA99, B6 69 EB 74 CA 38 74 18  82 9C 57 9F 78 D2 3B C4
i.e. giving the key length (1024), the Key ID (4960EA99) and the fingerprint (B6 69 EB 74 CA 38 74 18 82 9C 57 9F 78 D2 3B C4) as returned by `pgp -kvc'.
If things don't go smoothly (e.g. your unix ID is not your CRSID), follow these instructions.
Once you have generated a key, register it

Keys should be 1024 bits

Keys less than 1024 bits aren't really very secure.
Keys more than 1024 bits do not work on some old versions of PGP.
A shorter key for "testing" does not speed up testing much.
Using a short key for "less secure" things (e.g. if the secret key is held on a syetem which is insecure and the net may be tapped, so the pass phrase seen) might appeal as a warning, but many people won't notice the length of the key.

All IDs should should be signed by the key itself

To let people know that some (malicious) user hasn't added a spurious ID to your key, always sign valid IDs with your own key.

Keys should be RSA

To allow backwards compatability with PGP 2.x, all keys should be RSA.

The primary ID should be signed by the departmental accreditors

The departmental accreditors' keys will themselves be signed, to show that they do indeed belong to official departmental accreditors. This allows new keys to get a reasonable start in life, without users having to go round asking to have their keys signed by everyone they meet.
This is not an alternative to the standard "Web of trust", but a way to make it easy for users to get started.
To get a key signed, you will be asked to take a signed (in ink) printout of your fingerprint (pgp -kvvc | lpr) to one of the accreditors - at the tiem of writing, these roles are held by: pb (34659), maj (34647), gt (34630) or ckh (34686) -- phone first to chcek they are in.

The primary ID should be what recipients see after "From: "

Users should include secondary IDs for other email addresses which they have

When somebody wants to send you encrypted email, they (or their Mail User Agent) will use the recipient address to try to find a key to use. If you have another email address (e.g. pb@cl.cam.ac.uk rather than Piete.Brooks@cl.cam.ac.uk), publish that ID as well.
However, this should not include Role aliases (such as postmaster), as these may change. These should have their own keys.

Lab Key Ring

Users may care (from time to time) to load the keys of all members of the lab into their own key ring, using the command:
pgp-key-add -c

To load an individual key, use the local pgp-key-add command, as in `pgp-key-add pb'.

Low integraty trust info

The correct way to check the credibility of a User ID is through the "Web of Trust" of signed credentials. However, people also use low integraty channels such as putting the fingerprint of their PGP key in their signature, in their .plan, etc.
Comments to pb or webmaster
More info on PGP at cl.cam.ac.uk and cl.cam.ac.uk info
blanks to allow NAMEs to be at the top of the page