Mailing List Archive

Hi Phil,

Am Freitag 22 Oktober 2021 17:00:11 schrieb Phil Pennock via Gnupg-users:
> I think what I _want_ is `trust-model pgp+federated+tofu`, which means,
> in order: (1) any sigs from the WoT; (2) origin information from the
> key, if the origin shows the key was safely retrieved from a federated
> origin in a provable way (WKD, various DNSSEC storage options, etc); (3)
> TOFU as a fallback if there's nothing better.
>
> I might even just want `trust-model pgp+federated` if I'm feeling more
> cautious. ?But in reality tofu helps a little.
>
> Does this make sense to people? ?Is there a security problem with this?
> Does this seem like a reasonable feature request?

Yes, not really, yes. ;)

To me it is important that the behaviour of the application using this
information is ideally not black and white, you probabaly now

https://wiki.gnupg.org/AutomatedEncryption

which is a vision how email clients can deal with pubkeys that they have
different levels of confidence in.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Hi Phil,

On Fri, 22 Oct 2021 17:00:11 +0200,
Phil Pennock via Gnupg-users wrote:
> When evaluating the trust we have in the identity attached to a key, I
> often see "WARNING: We have NO indication whether the key belongs to the
> person named as shown above"; at the same time, `--with-key-origin` for
> the very same key will show "origin=wkd".
>
> GnuPG uses the trust-model option to decide how to evaluate the trust we
> have in a key. I've looked through the options, and checked the release
> notes for the 2.3.x series to confirm nothing new there.
>
> I'm currently using "trust-model tofu+pgp"/"tofu-default-policy unknown"
>
> I think what I _want_ is `trust-model pgp+federated+tofu`, which means,
> in order: (1) any sigs from the WoT; (2) origin information from the
> key, if the origin shows the key was safely retrieved from a federated
> origin in a provable way (WKD, various DNSSEC storage options, etc); (3)
> TOFU as a fallback if there's nothing better.
>
> I might even just want `trust-model pgp+federated` if I'm feeling more
> cautious. But in reality tofu helps a little.
>
> Does this make sense to people? Is there a security problem with this?
> Does this seem like a reasonable feature request?

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.

:) Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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@pennock-tech.com=YYYY-MM-DD:email@example.org' \
--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@pennock-tech.com=${YYYY_MM_DD}:${URL}
https-web-fpr-src@pennock-tech.com=${YYYY_MM_DD}:${URL}
-- page only has fingerprint, key retrieved from keyservers
keybase@pennock-tech.com=${YYYY_MM_DD}:${KEYBASE_ID}
-- would nowadays just use public-account@
wkd-src@pennock-tech.com=${YYYY_MM_DD}:${EMAIL}
git-repo@pennock-tech.com=${YYYY_MM_DD}:${GIT_DESCRIBE}:${REPO_URL}
-- when there's an official project repo;
eg: 2020-01-15:b67a2b9:https://github.com/canterberry/nodejs-keys
`git describe --tags --always` for the field (haven't yet had to
escape colons in tags)
public-account@pennock-tech.com=${YYYY_MM_DD}:${SERVICE}:${ACCOUNT}
-- eg, github:foo -> <https://github.com/foo.gpg> (uploaded at <https://github.com/settings/keys>)

-Phil

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users