[ale] More Key Signing Followup

[Aaron Ruscetta]

I've signed all the keys of fully ID'd persons from our keyring group
using my original (and fully functional) 2048 bit "Freedom" key,
CADDA963.

I've pushed the signed keys up to big lumber and uploaded them
to the recommended key server.

I did not sign any of the keys with my new "stronger" key, since
I seem to have fat fingered the original pass phrase entry (twice)
and can not currently use it for signing or encrypting anything.
I'll be looking into writing a script to figure out where my fingers
were phat at some point.  Please feel free to ignore 5D62E6B4
and delete it from your copy of the key ring for the time being
(as I have done).

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.

====
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.

Admittedly, a lot of my hassles and wasted time this go round
were errors I introduced by rushing the steps of generating and
including a new key, but I still ran into lots of problems and
frustrations outside of trying to fix those broken bits.

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) .

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).

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.

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.

peace
aaron