trust-model and federated lookups

Phil Pennock gnupg-users at
Mon Oct 25 19:26:59 CEST 2021

On 2021-10-25 at 15:12 +0200, Neal H. Walfield wrote:
> This absolutely makes sense.  One way to model this in the web of
> trust is to imagine that you have a "WKD key," which you consider a
> partially trusted introducer, and which certifies keys that you
> retrieve via WKD.  Practically, it's a bit more complicated using the
> available mechanisms.

Oh, I do this now, for keys which I care about, but since GnuPG started
tracking origin information it just seems to be something which could be
more automated.

Specifically, I have a laptop-only key which I don't advertise, but is
trusted by my various other boxes, and it uses `--lsign-key` with a
`--cert-notation` for various scenarios.

So for WKD:
  gpg \
    --cert-notation 'wkd-src at at' \
    --lsign-key 0xDEADBEEF

Thus I have WKD introduction as trusted already, I'm just hoping to have
to do less and instead leverage the information GnuPG is already
tracking, with GnuPG issuing fewer scary warnings for _all_ users, not
just those who understand cert notations and local sigs.

My cert-notations patterns for lsigns to date are here, in case they're
helpful to others, whether for copying or because it informs trust
storage models:

  https-web-src at${YYYY_MM_DD}:${URL}
  https-web-fpr-src at${YYYY_MM_DD}:${URL}
    -- page only has fingerprint, key retrieved from keyservers
  keybase at${YYYY_MM_DD}:${KEYBASE_ID}
    -- would nowadays just use public-account@
  wkd-src at${YYYY_MM_DD}:${EMAIL}
  git-repo at${YYYY_MM_DD}:${GIT_DESCRIBE}:${REPO_URL}
    -- when there's an official project repo;
       eg: 2020-01-15:b67a2b9:
       `git describe --tags --always` for the field (haven't yet had to
       escape colons in tags)
  public-account at${YYYY_MM_DD}:${SERVICE}:${ACCOUNT}
    -- eg, github:foo -> <> (uploaded at <>)


More information about the Gnupg-users mailing list