Strange trust problem
Sat Feb 2 04:45:02 2002
I'm having a strange problem trying to check the "validity" of a key.
This is a rather long email, but it's important to understanding the
problem I'm having. First, a little background on how I'm using GPG.
I have a massively-distributed architecture of Unix boxes. I have
literally thousands of servers. I need to maintain all of them. I
have a small cron job running on each of them that downloads a set of
files every so often. After downloading the files, I want to
authenticate them to make sure that the "proper people" have given
the files their imprimatur.
I'm using GPG and digital signatures to verify the downloaded files.
I require at least two separate digital signatures per file, and every
digital signature that is used must be signed by one of a list of
hard-coded, well-defined "root" users. All clients know who the "root
What this means in GPG terms is that every file is doubly-signed using
a DSA key by two separate people. Each key used to sign a downloaded
file must be itself signed by one of a set of "root keys" (not
necessarily by the same "root key").
Here's how I'm handling this. I'm creating a number of gpg homedirs;
one for every "root key". Then when I run gpg, I use "--homedir
First I verify the signature is good with:
gpg --homedir <root user #1> --verify <file>
And check $?. If that succeeds, I "decrypt" the file (actually just
stripping off the signature) with:
gpg --homedir <root user #1> --decrypt --output <file2> <file>
Then I grab the fingerprint of the key used to sign the file:
gpg --homedir <root user #1> --batch --verify --status-fd 1 <file>
I search for "VALIDSIG", and then grab the third field, which is the
fingerprint. So far, so good.
Then, I need to make sure that the key associated with that
fingerprint has been signed by at least two "root users". So, for
each (known) root user, I do this:
gpg --homedir <root user X> --trusted-key <ID of root user X> \
--list-keys --with-colons <fingerprint>
Then I grab the second field, which is the 'validity' field. It'll be
a "q" for unknown, "f" for fully valid, or a "u" for ultimate (in the
case where <root user X> is the same as <fingerprint>).
I'm having a problem where the fingerprint I'm checking is coming up
as "q" for every user I test it against except itself. But if I
manually do "--check-sigs" against that key, it's been signed by *all*
of the root keys. Here's some output so that you can see what I'm
First, look at the signatures on the key:
[<host>:<dir>]# gpg --homedir <path>/.gnupg-1111111111111111 --trusted-key 1111111111111111 --check-sigs 2222222222222222
pub 1024D/22222222 2002-02-01 Username #2
sig! 22222222 2002-02-01 Username #2
sig! 11111111 2002-02-02 Username #1
As you can see, the key 2222... is signed by 11111111. That's the
same as my trusted-key, and my homedir. It's also signed by itself,
of course. But if I do "--list-keys --with-colons", this shows up:
[<host>:<dir>]# gpg --homedir <path>/.gnupg-1111111111111111 --trusted-key 1111111111111111 --list-keys --with-colons 2222222222222222
Notice that the validity is "q". Why is this? The key "2222" has
been signed by user "1111". I'm telling gpg that user "1111" is the
trusted-key. Why is the key for "2222" not valid?
Thanks in advance for any help here! :)
Mark K. Pettit "Ragged lines of ragged grey
firstname.lastname@example.org Skeletons they shuffle away"
Yahoo!, Inc., 701 First Avenue, Sunnyvale, CA 94089