A sapling matures: meet sq 1.0

[Posted December 16, 2024 by jzb]

The Sequoia PGP project has announced version 1.0 of the sq command-line tool for managing OpenPGP encryption and signatures. It also provides a decentralized public key infrastructure (PKI), and key management facilities. This is the first stable release since development began on the project in 2017.

sq's PKI is probably its most notable feature, and the one we invested the most time in. The PKI is used to authenticate certificates, and messages. Authentication is necessary to ensure that you are encrypting to the person you think you are, and to identify who really authored a message; without authentication, encryption and verification are much weaker.

I’d like to see an article!

Posted Dec 18, 2024 3:29 UTC (Wed) by intelfx (subscriber, #130118) [Link] (23 responses)

In case our editors need even more ~~stuff in their backlog~~ suggestions for future articles, I’d be very interested in a full-length one on Sequoia and sq (and how their PKI model is similar/different/more/less useful than the venerable PGP web-of-trust, or whatever it has degenerated into by 2024).

I’d like to see an article!

Posted Dec 18, 2024 9:23 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (1 responses)

And, Debian wants to replace gpg for apt.

I’d like to see an article!

Posted Dec 18, 2024 16:32 UTC (Wed) by lathiat (subscriber, #18567) [Link]

Well that was quick:
https://fosstodon.org/@juliank@mastodon.social/1136728102...

"apt in experimental verifies repositories using sqv"

I’d like to see an article!

Posted Dec 18, 2024 9:34 UTC (Wed) by taladar (subscriber, #68407) [Link] (6 responses)

I would also like that article and have some sort of migration from existing GPG keys included in it if possible since that is one of the things I couldn't quite figure out on my own (importing keys is easy enough but I couldn't find out how to mark them as trust anchors the same way the ultimate/full/... trust works in GPG)

I’d like to see an article!

Posted Dec 18, 2024 17:17 UTC (Wed) by lunaryorn (subscriber, #111088) [Link] (4 responses)

I'm not very familiar with the internals and the cryptographic principles of either implementation, but from a practical standpoint the sqv command line interface is a lot simpler and more reliable for scripting and automated use.

I’d like to see an article!

Posted Dec 18, 2024 18:34 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

Presumably its library API also doesn't involve shelling out to the executable and parsing output…

I’d like to see an article!

Posted Dec 21, 2024 9:02 UTC (Sat) by neal (subscriber, #7439) [Link]

Correct. sq uses our libraries, not the other way around. They provide a lot more functionality than sq; sq provides a relatively high-level API.

I’d like to see an article!

Posted Dec 19, 2024 8:48 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

I didn't really see any machine-readable output options either but I would probably use the Rust library crate if I wanted to automate it.

I’d like to see an article!

Posted Dec 21, 2024 8:59 UTC (Sat) by neal (subscriber, #7439) [Link]

sq's CLI is stable in the sense that we're not going to change the command names, the argument names, the semantics, or the exit codes. We're still going to fix bugs of course, and we'll make backwards compatible changes like adding new features.

To provide some forward compatibility, if you need to use some API that was introduced with version x.y.z of sq, you can assert that sq implements that version of the interface using the --cli-version argument:

$ sq --cli-version x.y.z ...

This also allows a single sq binary to implement multiple versions of the CLI.

The human readable output is indeed not stable, but we hope to extend sq in 2025 to add machine readable output to all commands.

I’d like to see an article!

Posted Dec 21, 2024 8:47 UTC (Sat) by neal (subscriber, #7439) [Link]

sq automatically imports certificates from gpg's certificates store (and monitors it for updates), and it uses secret key material managed by gpg-agent. But you're right, sq doesn't import gpg's trust roots: that's quite fragile. To add a trust root, you run:

$ sq pki link authorize --cert FINGERPRINT --all --unconstrained

I’d like to see an article!

Posted Dec 18, 2024 12:11 UTC (Wed) by Lennie (subscriber, #49641) [Link] (10 responses)

If I had a quick look on their website, seems to just be a Rust implementation of regular OpenPGP ?

With added nice-to-have features.

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

Posted Dec 18, 2024 12:20 UTC (Wed) by farnz (subscriber, #17727) [Link] (8 responses)

They've changed enough details about the Web of Trust's behaviour that it's interesting - for example, being able to say that I trust the key I associate with an LWN editor for user IDs ending @lwn.net, but not for user IDs with any other ending.

I have a soft spot for the ideals behind the WoT, but the implementation has always been lacking, and the social expectations around the implementation unreasonable. At a glance, Sequoia's implementation looks like it might be an improvement on GnuPG's, and allow for weaker social expectations, but I'd love to see a proper article about it.

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

Posted Dec 18, 2024 13:18 UTC (Wed) by daroc (editor, #160859) [Link]

As it happens, I'd like to see an article about this too. I'll make sure that it gets added to my research queue if Joe doesn't want to do a follow-up.

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

Posted Dec 19, 2024 9:08 UTC (Thu) by grawity (subscriber, #80596) [Link] (1 responses)

> They've changed enough details about the Web of Trust's behaviour that it's interesting - for example, being able to say that I trust the key I associate with an LWN editor for user IDs ending @lwn.net, but not for user IDs with any other ending.

As in user IDs belonging to the key in question, or as in vouching for other keys' user IDs? The ability to sign/lsign individual user IDs *was* present in GnuPG and other PGP software, as I recall...

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

Posted Dec 19, 2024 9:56 UTC (Thu) by farnz (subscriber, #17727) [Link]

As in vouching for other keys' user IDs. I can, for example, say (using GnuPG's terms for trust levels) that the key I've named lwn@lwn.net is fully trusted to vouch for the user ID to key binding for user IDs ending @lwn.net, but only marginally trusted for other keys. Or I could say that I trust big.boss@mybank.com fully for @mybank.com, marginally for @visa.com and @mastercard.com, but not at all trusted for other user IDs.

Signing/lsigning individual user IDs is just vouching for that user ID, as far as I'm concerned - it's the extra nuances in trust that makes it feel qualitatively different to GnuPG to me (especially since I might know that big.boss@mybank.com is lazy about checking ID etc, unless the HR team at MyBank has done a full check).

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

Posted Dec 21, 2024 11:13 UTC (Sat) by gouttegd (guest, #106484) [Link] (4 responses)

Err, this is not new, it’s a “trust signature” with an associated domain restriction. This was already described in RFC 4880, sections §5.3.2.13 and §5.3.2.14 (https://datatracker.ietf.org/doc/html/rfc4880#section-5.2...). And I think it dates back to PGP 5 and its concept of “Trusted Introducer”. Supported by GnuPG with its key editor command `tsign`.

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) [Link] (3 responses)

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.

I’d like to see an article!

Posted Dec 18, 2024 23:14 UTC (Wed) by dsommers (subscriber, #55274) [Link]

More of the end-user tooling can be found here: https://sequoia-pgp.org/projects/

I’d like to see an article!

Posted Dec 18, 2024 14:01 UTC (Wed) by jake (editor, #205) [Link] (2 responses)

There is this article from 2020:

https://lwn.net/Articles/830902/

jake

I’d like to see an article!

Posted Dec 18, 2024 14:13 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

There is, but it very explicitly does not talk about the sq tool or any of the high-level features of Sequoia, because they didn’t exist / weren’t ready by the time that article was written :-)

I’d like to see an article!

Posted Dec 18, 2024 23:18 UTC (Wed) by dsommers (subscriber, #55274) [Link]

Have a look here:

https://sequoia-pgp.org/projects/