I’d like to see an article on Sequoia's variant of the OpenPGP Web of Trust

Posted Dec 21, 2024 17:17 UTC (Sat) by farnz (subscriber, #17727)
In reply to: I’d like to see an article on Sequoia's variant of the OpenPGP Web of Trust by gouttegd
Parent article: A sapling matures: meet sq 1.0

I can't find tsign in the GNU Privacy Handbook. If it's something that GnuPG actually supports now, that's great, but it doesn't appear to be well-documented if so. And for cryptographic trust stuff, "it exists but we don't bother documenting it - we assume that you'll work it out if you care" is itself problematic.

Further, the RFC 4880 text is very different to what Sequoia offers; it's not a trust signature, since a trust signature carries with it the statement that I, as the entity signing this key, believe that it's a valid key (all trust signatures are also validity signatures). What Sequoia offers is a way for me to say "if the WoT says this key is valid, then trust it (but do not sign it) for cases where it's signed a key that matches this requirement".

This difference may be subtle, but it's important - it means that I can say to Sequoia "I have no idea whether bigboss@mybank.com is the owner of this key, but if they are the owner of the key as per the rules of the WoT, then I trust them to authoritatively sign @mybank.com and marginally sign @visa.com", whereas Trusted Introducers as laid out in RFC 4880 only lets me say "I know that this key belongs to bigboss@mybank.com, and so I trust them etc". If I don't know that a key is valid, RFC 4880 is not applicable, since it only cares about interchange messages (and if I'm not claiming that there's validity, then there's nothing to interchange, since my trust decisions are fully local). And I can't find a GnuPG command that allows me to indicate restricted trust without at least signing the key, which is the wrong operation to use, since I don't want to make any assertions about validity (which is what signing is for), I just want to make an assertion about trust in the event the WoT tells me that the key is valid.

I’d like to see an article on Sequoia's variant of the OpenPGP Web of Trust

Posted Dec 22, 2024 9:29 UTC (Sun) by gouttegd (guest, #106484) [Link] (2 responses)

> I can't find tsign in the GNU Privacy Handbook.

It’s mentioned in the manual and info page – though I’ll admit the description of what it does is sparse, and merely refers to the RFC 4880 “for more information”.

> Further, the RFC 4880 text is very different to what Sequoia offers; it's _not_ a trust signature

Hum, are we talking about the same thing? I refer to `sq pki vouch authorize`, which according to both its manual page (https://sequoia-pgp.gitlab.io/sequoia-sq/man/sq-pki-vouch-authorize.1.html) and its description in Sequoia’s handbook (https://user-documentation-sequoia-pgp-761d1476704b33af841fb727ea0f4fb2.gitlab.io/cert_certify.html) certainly sounds _exactly_ like it merely implements the OpenPGP’s “trusted introducer” concept.

If you are referring to another feature of Sequoia that I am not aware of (which is entirely possible – I have not tried Sequoia), can you point to which feature exactly you are talking about?

I’d like to see an article on Sequoia's variant of the OpenPGP Web of Trust

Posted Dec 24, 2024 12:09 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

We are not; I am referring to sq pki link authorize, which is entirely local to your trust store, and doesn't (as far as I can tell) mark the linked key as valid; it merely makes it act as a trusted introducer once it's deemed valid by other means.

I would agree that there's nothing in sq pki vouch that you can't do in GnuPG; it's the stuff in sq pki link that feels like an improvement - it is, however, possible that you can do it all in GnuPG, it's just that it's much better documented in Sequoia.

I’d like to see an article on Sequoia's variant of the OpenPGP Web of Trust

Posted Dec 24, 2024 20:09 UTC (Tue) by gouttegd (guest, #106484) [Link]

I see, thank you.

So it is a trust signature that is (1) local and (2) emitted by a specific key, which is _not_ the user’s own key but instead the key of the “trust store” (the “Local Trust Root”).

> it doesn't (as far as I can tell) mark the linked key as valid

I tested. It _does_ mark the linked as valid -- which is completely expected: the fact that the trust signature is local is irrelevant, and the fact that it is not emitted by the “Local Trust Root” instead of the user’s own key does not matter since that local trust root key is ultimately trusted.

> it's the stuff in sq pki link that feels like an improvement

Local signatures are as old as OpenPGP (they were already specified in RFC 2440), so that part hardly qualifies as an improvement.

The real new thing, as far as I know, is the idea of having a completely separate key to manage the trust store. It would be possible to do something like that with GnuPG but there is no built-in support for it (contrary to local signatures), so if you wanted to do it you would need to to it “manually” (create yourself a key completely distinct from your own key, and use only that key to manage your certifications).

It’s certainly a clever idea, but I do have some reservations about the way it is implemented. In particular, the “Local Trust Root” key is _not_ password-protected and is basically stored in plain text. For a key that is ultimately trusted, even if its only purpose is to manage certifications, that’s a strong no-no for me.