[ale] More Key Signing Followup

[Michael B. Trausch]

On 12/15/2011 06:21 PM, Aaron Ruscetta wrote:
> I have decided not to bother creating a replacement key at this
> time, but thanks for the offers to sign it if I provided proof of
> origination by signing the fingerprint with my working key.

If you change your mind at some point, the offer will be just as valid
then as it is now.  :-)

> Thoughts on the process of managing PGP keys:
> 
> This my third time around with this gpg key stuff and I continue
> to find everything about this process cryptic (no pun intended),
> confusing, frustrating and a massive time vacuum.

To get started using any sort of thing like OpenPGP (which GnuPG is an
implementation of, more or less) can be a bit overwhelming, particularly
if you aren't using tool wrappers around the command line program
itself.  My daily use of it is mostly "behind the scenes" to me; the
agent handles passphrase caching pretty transparently, as does the mail
client.  In my case, I am (currently) using Thunderbird, but Evolution
works just as well with OpenPGP messages.

Because most of my use for the key is in fact email, I don't actually
directly interact with the gpg command line program often.  So, every
time I need to do something with it, I have to look up the man page
until I find what it is I am looking for---because I have inevitably
forgotten it.  Don't get me wrong; I'm not complaining about the command
line!  Just one of those "use it or lose it" things, and I'd rather lose
one really complex command's options from my memory than all the
standard stuff from the toolbox.  :)

What system are you running on?  You should be able to pick a decent
mail client (regardless of your processor architecture) that has
built-in or extension-based support for GnuPG.  Claws, Mozilla
Thunderbird and Evolution all support it pretty straightforwardly (I
have used all three at various points in time).  There is also a list of
plugins and user interfaces here:

  http://www.gnupg.org/related_software/frontends.html

Like many other things, if you use it all the time it just kind of fades
into the background.  When I go to sign tarballs, I can never remember
anything other than "gpg --armor"... :-)

> Most of the additional issues come from what I found to be
> huge inconsistencies in the use of KEY ID / UID terminology
> in the gpg argument strings, man pages and other
> documentation.   In some cases, Key ID was used to refer to
> the user ID (e.g. "Michael H. Warfield").  For signing, where
> the man page indicates a "Key ID" argument, only the
> UID would work for me and the program balked at using
> any actual 8 character Key ID's.  Other places, like uploading
> the keys to a key server, the Key ID of the man page was
> referring to (and ONLY referring to) the actual 8 character
> hex ID string (which I learned could be optionally set
> to be 16 characters by another command argument) .

Sadly, this kind of thing can be found everywhere, and it really is
discouraging.  Personally, I try to use the terms "uid" and "key ID"
consistently (and meaning the user name/email address and the tail of
the key's fingerprint, respectively).  Then again, (in)consistency in
naming has often been a pet peeve of mine.

> The process of Exporting-keys to upload to the Keyring site
> (biglumber) and Sending-keys to the key servers was made
> additionally annoying and time consuming by the apparent
> lack of [easy to include] tools or command arguments that
> would simply produce a list of JUST the Key ID's or JUST
> the UID's from a person's keyring DB.  The best I could do
> for getting a "batch" list of the Key or User ID's was to dump
> the whole key listing to text file and then manually edit out
> the irrelevant cruft (which you get to do twice, since one
> operation wanted UID's and the other wanted Key ID's).

The way that I did this was with a one-off pipeline...

... I use far too many one-off pipelines.  :-)

The command I used to get the list of key IDs was (sorry, these span
multiple lines...):

$ gpg --list-keys | grep pub | awk '{ print $2 }' | cut -f2 -d/ | sort |
tail -n+2

To export the keys from the list, then:

$ gpg --armor --export $(gpg --list-keys | grep pub | awk '{ print $2 }'
| cut -f2 -d/ | sort | tail -n+2)

I suppose I should try to remember to capture all of these pipelines I
create as one-offs and put them in some sort of a small collection of
shell scripts.

> Using the keys after you get them also remains less than
> simple, as only a couple of specific mail client versions
> are supported on my slightly older platform.  Tools for using
> gpg keys within the web mail clients like gmail seem to be
> available for newer web browser versions, but not for
> anything that still runs on PPC.

One thing that comes to mind, if you don't mind terminal applications:
mutt handles OpenPGP messages pretty well after a bit of configuration.

Also, Claws might be something you want to look into, as well.

> I definitely got a lot further toward a clear understanding
> the gpg key mechanisms and usage and management
> with this foray, even more than I did when I helped prepare
> the documentation for the last ALE key signing event in
> 2009. The disappointment is that a lot of my new found
> understanding is the knowing that the gpg key processes
> are cryptic (no pun intended), confusing, frustrating and
> a massive time vacuum.
> 
> Even for a fairly competent shell mechanic like myself, the
> whole key management process seems a major PITA that
> could due to be greatly simplified (or at least much better
> explained) so that the benefits of public key encryption can
> be enjoyed and employed by a much broader audience.

I agree that there could be better (more intuitive, and more robust)
front-ends, at least compared to the ones that I have seen and used.  I
haven't used them all, of course, but the ones that I have found have
had issues here and there.  Thing is, I'm not entirely certain how to
make it more convenient without getting rid of some of its benefits;
lowering the bar, so to speak, would very likely have the potential to
also lower the quality of the Web of Trust and so forth.

	--- Mike


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 729 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20111215/8cd23d9e/attachment.bin