27 05 | 2011

PGP signatures with trust and verification level

Written by Tanguy

Classified in : Homepage, Debian, To remember

Identity checks and trust

Saint Peter's key, detail from a stone statue

The OpenPGP web of trust is composed of keys linked to each other by two things:

  • identity checks: signing a key means that you verified the link between a key with user IDs, an official identity document with a photograph, and a person with a face;
  • trust: on your public key ring, you manually decide who you trust to correctly check other people's identity.

With these two pieces of information, GnuPG is able to determine whether or not the key of someone you never met can trusted to belong to its alleged owner.


Signing a key is usually a binary action: either you sign it or you do not sign it. Thus your signature on a key will give other people a rough identity check information and no trust information at all.

In fact, the OpenPGP standard does allow to publish precise identity check and trust information on signatures, but unfortunately this is now enabled with GnuPG by default. These features are called certification level and trust signatures.

Certification level

To indicate how careful you verified someone's identity, run GnuPG with the option --ask-cert-level, or add ask-cert-level to your configuration file .gnupg/gpg.conf.

When you make a signature with this option, GnuPG will ask you how carefully you verified the key owner's identity. According to the manpage gpg(1), the available levels are:

  • 0: no indication;
  • 1: personal belief but no verification, useful for signing pseudonymous IDs;
  • 2: casual verification;
  • 3: extensive verification.

Trust level

You can also indicate how much you trust someone, sign his key with the command tsign instead of sign. GnuPG will then ask you three questions:

  1. how far you trust him to verify other people's keys: marginally or fully (I personally only fully trust people that were trained or challenged by myself or by people I trust even more)
  2. how far you allow him to make trust signatures on your behalf: usually answer 1; answering 3 would allow him to issue trust signature with level 2, thus allowing other people to issue trust signatures on your behalf (this features exists to implement pyramidal certification systems, but can be interesting for signing your own keys when you have several);
  3. if you wish to restrict this signature to a domain: I have no idea of what this means so I give none.


Although certification level and trust signatures are not very widely used, thanks to GnuPG's default settings, it allows to publish more information about your signatures, adding value to the web of trust at no cost, which I believe is a good think. Thus I think it is worth doing it.

If you want to use these features with the caff wrapper, remember that it has its own GnuPG configuration .caff/gnupghome/gpg.conf. In addition it does not implement trust signatures natively: to use them, you have to abort the automatic signing, which gives you a GnuPG prompt, where you are then able to tsign, then exit to return to caff that will consider your trust signatures.



friday 27 may 2011 à 07:23 Daniel Kahn Gillmor said : #1

I'm not convinced that adding more detail to your OpenPGP certifications is necessarily positive. I tend to think that we should use the public WoT to establish a baseline of *identity*, and that making it more complex than that actually causes the public certifications to leak more information about personal relationships than we need it to.

I've never seen any tool make use of "Certification level" (and WoT inference is certainly confusing/complex enough without them) -- so adding that information is really only likely to give extra hints to people interested in mining your social relationships for data (they can focus more on your "extensive verification" certifications).

"Trust signatures" in certifications are potentially quite dangerous in several ways. Indicating Trust level exposes you to some risk: An attacker who wants to convince you of a bogus key+identity needs to get that key certified by someone that you trust. If you publish your entire trust set in your certifications) (ownertrust in gpg is by default a privately-held preference), you're making that attacker's job much easier.

Trust depth is troublesome because it extends that same risk to everyone who depends on you for certification; if you publish a trust depth of > 1, then everyone who is willing to accept certifications made by you is now vulnerable to an attack on any of the keys in question. This is like an X.509 Certificate Authority granting blanket Certficate Authority status to a child CA. They actually do this in the X.509 world, and it's one of the many reasons that X.509 is problematic:


Domain-scoping of trust signatures are a mitigating factor -- you can say "i trust this Maria Sanchez to reliably certify any key with an associated e-mail address within the foo.example domain (i.e. ending with @foo.example)". This is useful because it means that you're willing to accept Maria Sanchez has control over that domain, and can legitimately introduce you to anyone within it; but you don't need to automatically believe her when she tries to introduce you to "Barack Obama <president@whitehouse.gov>". That said, almost no one uses domain-scoping, and the way it's implemented (regex-filtering within a trust-sig) has some potentially dubious aspects. Using a trust-sig within a non-exportable signature as a way to avoid setting blanket ownertrust is probably reasonable; that way you get the benefit of scoping without leaking the relationship info to the outside world. But i don't know many people who operate this way.

Here is a related post i made to gnupg-users recently pushing back against storing more relationship data in OpenPGP certifications:


friday 14 december 2012 à 15:27 derp said : #2

additional info + domain explained:

Write a comment

What is the first letter of the word qillj? :