SQ(1)

πŸ’– SQ(1) β€” the manual, but make it make sense πŸ’–

okay bestie, this one's called sq-pki-authenticate and it lives in the User Commands corner of the manual. it authenticates a binding. that's the whole vibe. let's get into it ✨


✨ NAME ✨

sq-pki-authenticate β€” authenticate a binding 🫢


🌸 SYNOPSIS 🌸

sq pki authenticate [OPTIONS]

πŸ¦‹ DESCRIPTION πŸ¦‹

So. You wanna authenticate a binding. A binding is a certificate plus a User ID, btw β€” like, they're holding hands 🫱🫲.

How do we do it? We go hunting for a path from the trust roots to the binding you asked about, wandering through the Web of Trust. And listen β€” certifications can be like "hmm, I kind of vouch for this" (aka marked as conveying only partial or marginal trust), so sometimes it takes multiple paths to actually get there. no single path is gonna carry the whole thing, yk?

If nothing can be authenticated to the level you asked for, you get an error. And the default level is fully authenticated β€” that's a trust amount of 120, fyi.

πŸ’… but here's the cute part: if any valid paths to the binding get found, they get printed on stdout β€” whether or not they were enough to actually authenticate the binding. we show receipts either way, periodt.

πŸŽ€ OPTIONS πŸŽ€

πŸ’œ Subcommand options

  • --amount=AMOUNT β€” the required amount of trust.

120 means full authentication. anything less than 120 means partial authentication. and when you pass --certification-network, this defaults to 1200 β€” like, this command is out here trying to find 10 paths. go big or go home ✨

  • --cert=FINGERPRINT|KEYID β€” use certificates with the specified fingerprint or key ID. πŸ”‘
  • --certification-network β€” treats the network as a certification network.

Normally the authentication machinery treats the Web of Trust as an authentication network, where a certification only means the binding is correct β€” it does not mean the target should be treated as a trusted introducer. But in a certification network, the targets of certifications get treated as trusted introducers with infinite depth, and any regular expressions are ignored. Note: the trust amount stays unchanged. and this is literally how most of the so-called PGP path-finding algorithms work. iykyk 🧚

  • --email=EMAIL β€” authenticate the specified email address.

This checks whether it's possible to authenticate a user ID with that email address. and the user IDs do not need to be self signed. 🫢 if you want to authenticate a user ID containing just the specified email address, use --userid <EMAIL>.

  • --gossip β€” treats all certificates as unreliable trust roots.

This is the move for figuring out what other people think about a certificate β€” aka gossip or hearsay. In other words: it finds arbitrary paths to a particular certificate.

Gossip is genuinely so useful for spotting alternative ways to authenticate a certificate. Storytime πŸ“–: imagine Ed wants to authenticate Laura's certificate, but asking her directly is inconvenient. Ed discovers that Micah has certified Laura's certificate β€” but Ed hasn't yet authenticated Micah's certificate. If Ed is willing to rely on Micah as a trusted introducer, and authenticating Micah's certificate is easier than authenticating Laura's certificate, then Ed has just learned about an easier way to authenticate Laura's certificate. ate that πŸ‘‘

Stable since 1.1.0.

  • --show-paths β€” show why a binding is authenticated.

By default, only a user ID and certificate binding's degree of authentication (a value between 0 and 120) is shown. This changes the output so it also shows how that value was computed, by showing the paths from the trust roots to the bindings. we're doing math in public bestie πŸ”₯

  • --unusable β€” show bindings that are unusable.

Normally, unusable certificates and bindings are not shown. This option considers bindings even if they are not unusable, because they (or the certificates) are not valid according to the policy, are revoked, or are not live.

⚠️ this option only makes sense with --gossip, because unusable bindings are still considered unauthenticated.

Stable since 1.1.0.

  • --userid=USERID β€” authenticate the specified user ID.

the specified user ID does not need to be self signed. πŸ™ˆ

🌈 Global options

See sq(1) for a description of the global options. (aka the shared lore, go read it πŸ’–)


⭐ EXAMPLES ⭐

Authenticate a specific binding. classic move:

sq pki authenticate --cert \
       EB28F26E2739A4870ECC47726F0073F60FD0CBF0 --userid \
       "Alice <alice@example.org>"

Check whether we can authenticate any user ID with the specified email address for the given certificate. lowkey my fave:

sq pki authenticate --cert \
       EB28F26E2739A4870ECC47726F0073F60FD0CBF0 --email \
       alice@example.org

🧚 SEE ALSO 🧚

sq(1), sq-pki(1).

For the full documentation see <https://book.sequoia-pgp.org/>. πŸ“šβœ¨


πŸ‘‘ VERSION πŸ‘‘

1.5.0


and that's the whole page, bestie!! πŸŽ€βœ¨ this was Sequoia PGP version 1.5.0 energy from top to bottom β€” the manual even stamped 1.5.0 on the version line, matching its own footer, so we're consistent and slaying πŸ’… mwah, go authenticate something, ily πŸ«ΆπŸ’–

πŸ“¦ where this page comes from