determine the source(s) of validity

Peter Lebbing peter at
Mon Dec 9 11:16:03 CET 2013

Hash: SHA1

On 08/12/13 22:11, Hauke Laging wrote:
> IIRC this has been discussed here a while ago and there is no way to get
> this information from GnuPG. I would like to know whether there is already
> software available which does this; no need to reinvent the wheel.

The Debian package signing-party has some tools working on this info, but I
don't think you can get the information you're really after, unfortunately. It
goes some way towards achieving it, though.

$ gpg --list-sig|sig2dot >

will create a .dot file for Graphviz and similar tools that has keys as nodes
and signatures as edges.

$ springgraph < >sigs.png

will create a picture of that graph; it's an alternative tool to the ones
provided by Graphviz.

Some other statistics can be had by:

$ pgpring -S -k ~/.gnupg/pubring.gpg|process_keys >preprocess.keys
$ keyanalyze

The first command will create a file preprocess.keys and the second a
directory called 'output' with distance analysis and stuff on the keys.

None of these commands take the trust database into account, AFAIK[1]. A
program that would take the output of --export-trustdb and the file
and annotates it with validity information would be cool. Perhaps pruning to only include valid signatures.

> If there isn't any I would do this (but maybe there is a better approach):

I think the better approach is to write a tool combining --export-trustdb and
the file ;).

> BTW: I noticed that a key becomes invalid if its certifying key expires and
> has complete trust. But if it has ultimate trust then the expiration does
> not make the certification invalid. Is this intentional?

I think it's intentional. You would typically use ultimate trust for your own
keys. And if your own key expires, you might still very well trust the
certifications you made with that key. If the key of a fully trusted person
expires, that key no longer "validly represents" that person, and perhaps its
certifications can't be trusted anymore. I suppose the bond between you and an
ultimately trusted key is so strong that you are supposed to know all there is
to know about that key, and you should revoke the ultimate trust if you no
longer have ultimate trust in that key. Ultimate trust: I don't care what
anybody says, I believe in you.

> Another, related question: I was surprised to read the recommendation to
> create a local certification for keys which have been validated via the
> WoT. But the one who wrote that seems extremely competent to me with
> respect to OpenPGP. Is there a general concensus on that? What are your
> opinions?

In and of itself, it sounds unnecessary. The most important reason you would
make a local sig, is to make a key valid, but if it's already valid through
the Web of Trust, that's no longer necessary.

It also creates the burden of maintenance: through expiry or revocation of
keys and signatures, your WoT might at some point no longer consider a key to
be valid. But you did a local sig, so the key stays valid. You might not
notice that the validity has diminished.

But suppose that in certain scenario's, you consider a key (which isn't valid
yet) as "valid enough", but don't want to announce this to the world. I've
been pressing my point lately that I strongly believe your exportable
signatures should represent verification effort, not a belief of validity.
Still, you might want to use that belief of validity that you have to make a
key valid in your own keyring. This sounds like a perfect use case for a local

There might well be a scenario where you local-sign a key that's already valid
through the Web-of-Trust, but I can't think of one just now.



[1] Since you give either the public keyring file, or the output of gpg
- --list-sig, very explicit input that doesn't include trust, it seems highly
unlikely that those programs also access the trust database on their own.

- -- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <>

More information about the Gnupg-users mailing list