I don't have a doc available per se, but my own practices are mentioned in the key policy doc that I embed when I sign someone's key. It's available at http://undergrid.net/legal/gpg/ for the current version. The highlights are basically that I have 2 separate USB drives with encrypted filesystems, with both having different passphrases to decrypt them. I used to have a wiki page on how I setup my GPG environment with the USB keys themselves and the symlinks and configuration used. I need to resurrect this someday. One holds the primary keys and is stored in my firesafe along with revocation certificates both printed out and on CD and is only brought out to issue/revoke subkeys and to sign someone's key. The other has the subkeys and I carry with me daily. None of my GPG keys are ever stored on a computer and are instead always accessed directly off the USB drive when it's decrypted and mounted. My primary key does not have an expiration date on it, but my subkeys have an expiration set to no more than 30 months, I usually issue a new one after 24 months and begin using the new one after it's uploaded to the keyservers and revoke the old one 6 months later. Obviously as I mentioned I then embed the URL for the current key policy when I sign a key including the checksum. Over the years I've moved from using MD5 to SHA1 to SHA256 checksums. The policy itself is detached signed by each key that it relates to. I have separate keys for personal, Debian and work use. Regards, Jeremy Drew Scott Daniels wrote: > Hi, > Is there any good documentation about best practices for OpenPGP key > management? I plan to use gnupg (gpg), as it's conventional and seems like > the "best of breed" these days. > > Most documentation I've found seems significantly out of date (including > long discussions of incompatibilities with versions from 2001...). I did > find it interesting that the IDEA patents are expiring in May this year > for the EU and US if I remember > > The best documentation I have found includes: > http://arfore.com/2007/07/29/gpg-best-practices/ > http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/ > > Over the years I've heard some ideas like: > * Only store your key on less common architecture to make break-ins > involve more esoteric techniques (e.g. common rootkits/scripts fail). A > variant of this would be adding a level of virtual abstraction by using > a virtual machine (though it's just a level of obfuscation). > * Set an expiry date on your primary key and/or sub-key and sign a new > key before the old key expires. I think this is problematic for some > key reading programs though I can't remember any instances. Expiry > dates aren't default and seemed to be uncommon last time I checked. > * Revoke primary and/or sub-keys after expiration, or instead of > expiration. While revoking keys can keep people from using the old key > even if they cracked it, many programs might expect that revoked keys > aren't trustworthy at all. > * Use a really long keylength for your sub-key. The trade off seems to > be that signing and encrypting things takes a lot longer. > * Use a really long keylength for your primary key and > * Don't store your key on machines that connect to any networks. > Transferring signed data is time consuming, inconvenient... I'm not > sure if it's fair to say it's vulnerable to social engineering attacks. > * Use a random string for your passphrase. I was "bit" by this on my > first attempt to use a keypair years ago (around 2003). I forgot the > passphrase. > * "Harden" machines that contain your private key. While it's usually a > good idea to do this for all machines, I would hope that most things > would be secure without having to spend the extra time doing > configurations... > >>From the breakins over the years, and from the difficulties with "extra > secure" choices from some people, I really wonder whether best practices > aren't for a more secure key, but simply for good management of the > location of the key, the passphrase, the revocation data, and patients for > slow signing. > > I think key-pair usage could use: > * Default expiry times. This would make expiry more common. > * Implied expiry for old keys (though "old" isn't reliable). > * Use of the existing levels of security, or new levels as it seems the > highest level of trust is all too often required. > * Spliting trust of identity from trust of actions. SSL management has > personal, server, and program sections. Imagine signing someone's key > because you know who they are, then wanting to not trust code that they > write, or not trust that their signing of other peoples keys. > * SELinux policy to only allow certain programs access to private keys > made default. E.g. It would be nice if I could prevent scp from > accessing my private key without my explicit authorization by changing > the security context, or via a proxy program's authorization (the proxy > could log the event etc.). AppArmor to exclude access to the private > key is something I think that already happens. A nice guide to > implement the appropriate SELinux security context for a private key > would be nice, maybe I'm missing something from gnupg, fedora and/or > elsewhere. > > Please CC me on replies. > > Thanks, > > Drew Daniels > Resume: http://www.boxheap.net/ddaniels/resume.html > >
Attachment:
signature.asc
Description: OpenPGP digital signature