41

When I import signatures or receive a key with gpg, it outputs some cryptic lines like:

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:  16  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:  16  signed: 115  trust: 1-, 1q, 1n, 1m, 12f, 0u
gpg: depth: 2  valid: 105  signed: 189  trust: 81-, 11q, 0n, 4m, 9f, 0u
gpg: depth: 3  valid:  29  signed: 120  trust: 19-, 9q, 0n, 0m, 1f, 0u

I understand web-of-trust and asymmetric cryptography. But I don't know what "marginals", "valid", "signed" and all the letters behind trust exactly mean.

0

1 Answer 1

38

The official GnuPG documentation regarding this output is rather awkward.

The OpenPGP trust model

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model

By default, GnuPG uses the OpenPGP trust model. In this, you can put trust on a key, which allows it to validate other keys.

Trusted Keys

Keys can be trusted. Trust allows keys to validate other keys. Although trust is a kind of signature on other keys, it does not get distributed when uploading keys to key servers.

There are different trust levels:

  • - No ownertrust assigned / not yet calculated
  • e Trust calculation has failed; probably due to an expired key
  • q Not enough information for calculation
  • n Never trust this key
  • m Marginally trusted
  • f Fully trusted
  • u Ultimately trusted

(taken from the GnuPG manual, chapter key management)

Mostly important are the last three categories: your own keys are ultimately trusted; fully trusted keys' signatures are regarded equally worth your own ones; while marginal trusted keys require more signature paths to make a key valid.

Valid Keys

In the default OpenPGP trust model, a key is fully valid if:

  1. it is signed by enough valid keys, meaning
    • you have signed it personally,
    • it has been signed by one fully trusted key, or
    • it has been signed by three marginally trusted keys; and
  2. the path of signed keys leading from K back to your own key is five steps or shorter.

(taken from the GnuPG manual, chapter 'Validating other keys on your public keyring')

Other keys are marginally valid; showing there is a trust path, yet it is not strong enough. I highlighted the word "valid" in the quote above: only fully valid keys' trust is taken in account for calculating validity! In GnuPG, the default trust model can be configured.

The manual page linked directly above also contains some examples for trust calculation, but watch out for the non-default trust model applied for simplicity!

GnuPG's Trust DB Information

This information gets printed whenever the trust database gets updated, for example after receiving them from a key server.

gpg: depth: 0  valid:   1  signed:  16  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:  16  signed: 115  trust: 1-, 1q, 1n, 1m, 12f, 0u
gpg: depth: 2  valid: 105  signed: 189  trust: 81-, 11q, 0n, 4m, 9f, 0u
gpg: depth: 3  valid:  29  signed: 120  trust: 19-, 9q, 0n, 0m, 1f, 0u

This output describes your web of trust. The letters represent the trust levels listed above. On level 0, you will find your own (ultimately trusted) keys. There should not be any other kind of trust on this level. This key is valid (of course).

The further output represents my interpretation which is not based on reading the (missing) documentation nor the source code: You signed 16 keys, making all of them fully valid on level 1. For 12 of them you issued full trust, one of them only marginal. Those again lead to another 105 valid keys you trust on level 2. Some of them are trusted again, leading to another 29 valid keys in level 3.

Comparing this output to what the keyservers tell, you should probably update your keyring. ;)

More trusted keys in deeper levels could create the levels 0-5 if you do not change the maximum path length of five proposed by OpenPGP's trust model.


Werner Koch, the main author of GnuPG, once stated on the GnuPG mailing list:

You would need to look at the source. However, if you known the WoT well, you should be able to figure out what this is. [...] You should consider this a debugging output.

5
  • Thank you for this. But there is one thing that I don't understand. I downloaded the following keys that should have this chain: DEE1B495<->6991256E->66143B4C, and I set DEE1B495 as a ultimate key (just for testing this). But the output of trust_db doesn't show me depth 2, and depth one is with a "1q", what could be the missing information? When I check with "gpg --list-keys --list-options show-uid-validity", I see that DEE1B495 is set as "ultimate", 6991256E is set correctly as "full", the others outside the WoT are correctly set as "unknown" but the 66143B4C is set as "undef", I wonder why
    – Lilás
    Commented Nov 1, 2016 at 20:03
  • You probably set trust for 66143B4C to "don't know" (undef), which is different to "never set" (unkown). Otherwise, I'd expect this key to show up as valid, as it is signed by a valid and fully trusted key. Following the default GnuPG trust model, this key should also be considered valid. Will gpg --update-trustdb resolve the issue?
    – Jens Erat
    Commented Nov 1, 2016 at 20:27
  • gpg --update-trustdb doesn't solve. Is there a way to explicitly set to "never set" ? I changed DEE1B495 to "I don't know" instead of "ultimate", and now 66143B4C shows as [unknown]. I was wondering if this could be related to the --max-cert-depth, but the default is 5
    – Lilás
    Commented Nov 1, 2016 at 20:41
  • I'm not aware of a way to reset to "never set" without fiddling with the trust database (or exporting, modifying the rather readable export, removing all trust information, importing the modified trust backup again).
    – Jens Erat
    Commented Nov 5, 2016 at 16:54
  • Jens - You say, "Although trust is a kind of signature on other keys, it does not get distributed when uploading keys to key servers." What then, is the distinction between a Trust Signature and a Local Trust Signature (tsign & ltsign)? I am finding more mysteries regarding trust signatures. If you're willing to have a look, I'd appreciate it.
    – Diagon
    Commented Jul 29, 2020 at 21:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .