On Monday, March 03, 2014 16:06:38 Michael Muller wrote: > Here are some good documents I've found regarding GPG best practices: > > > http://wiki.debian.org/subkeys > https://we.riseup.net/riseuplabs+paow/openpgp-best-practices > > The first document, in particular, tells you how to set up a master key that > is kept separate from your subkeys, so if your day-to-day keyring is every > compromised, you can revoke your old subkeys and generate new ones and > carry on without losing all of your signatures.
I use a secret subkey for mobile devices, which seems like it's a commonly done thing by Debian developers as well; as such the actual "key signing" done for people's keys is usually done privately /after/ a "key signing" event rather than during the event itself. Thus the "key signing" event is for verifying people's identities and fingerprints to allow signing their keys later. There are some other interesting tricks one can play to "assemble" a full GPG key from separate pieces. Steve Langasek described doing this automatically using Upstart via triggers during one of the "Upstart vs Systemd" talks during DebConf13 in Switzerland. That sounded interesting. But I wanted to show what keys look like when you've only got a subkey installed (shown is my old key that I've set to expire soon): ------------------------------------------------------------------------------ $ gpg -K /home/<username>/.gnupg/secring.gpg -------------------------------- sec# 1024D/0x5E9E46254006EB3C 2003-05-14 [expires: 2014-07-20] uid Christopher R. Knadle <[email protected]> uid Christopher R. Knadle <[email protected]> uid Christopher R. Knadle <[email protected]> ssb 1024g/0x10CFE269A6B074D4 2003-05-14 ssb 2048R/0xCD1F4F1C841E5703 2011-07-15 ssb 2048R/0xD558D587A815EB84 2011-07-18 [...] sec 4096R/0x14A8E94F344E62E3 2013-01-19 [expires: 2019-01-18] uid Coredump Deb repo key <[email protected]> ssb 4096R/0x8E7D744597E0B7F5 2013-01-19 ------------------------------------------------------------------------------ Just like the document you pointed to states, the "sec#" denotes that the main secret key (that you'd use to sign keys with) isn't locally installed. However something else not shown (which is annoying); from the list it isn't clear /which/ subkey(s) listed are installed locally. Yuck. -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org https://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) Vassar College Mar 5 - 11th Anniversary Meeting - Home Network Show and Tell Apr 2 - Nginx: High-Performance HTTP Server, Reverse Proxy, and IMAP/POP3 Proxy Server May 7 - Google App Engine
