Search for a certificate on the internet

Certificates are necessary for encryption or for signature verification. The users of certificates are usually not the ones who created them, and this raises the question of how to make certificates available to interested parties. Since certificates in wire format are just plain files, they can be published on webservers or sent as email attachments, but these are individual solutions which differ for each certificate.

There are solutions which are more generic, in particular, servers in the internet that can be queried for certificates.

The first generation of these servers simply accept uploaded certificates and have a standardized interface for searching the inventory for User IDs. Anyone can upload any certificate, which makes the inventory a highly unreliable source.

Later solutions to the dissemination introduce hurdles to prevent the publishing of arbitrary certificates. As a side effect, this increases the likelihood that certificates stored on these servers are authentic.

Sequoia PGP uses four different types of these servers:

  1. SKS servers: These are "first generation" servers with unrestricted publishing.
  2. Keyservers which require a confirmation: An email is sent to each User ID in the certificate that resembles an email address containing a link which has to be clicked to acknowledge the upload. keys.openpgp.org works this way.
  3. Web Key Directories (WKD): The certificate is stored on a webserver, and its URL is constructed from the User ID (see Publishing certificates). As a side effect, WKD cannot be queried for fingerprints. WKD implies the control of a webserver related to the email domain of the User ID.
  4. DNS-based Authentication of Named Entities (DANE): Although it was not originally designed for OpenPGP certificates, DANE can be used for their dissemination. DANE implies control over the DNS zone file of the mail domain.

When retrieving certificates from these servers, Sequoia PGP stores not only the answer, but also its origin. Based on the origin, Sequoia PGP assigns an "authenticity value" to the certificate ranging from 0/120 (unauthenticated) to 120/120 (fully authenticated). These values accumulate, so certificates found on multiple servers gain authenticity. However, there is a cap of 40/120, which cannot be exceeded by this mechanism, thus preventing fully authenticated certificates generated simply by flooding the servers with duplicates.

This trust signature concept comes from the RFC9580 standard, which replaced RFC4880, used by OpenPGP.

Retrieving certificates

The easiest way to get a certificate is using the sq network search $USER_ID subcommand.

$ sq network search alice@example.com
Note: Created a local CA to record provenance information.
Note: See `sq pki link list --ca` and `sq pki link --help` for more information.

Importing 1 certificate into the certificate store:

  1. EE99C48D11A4BE940569C4B3919EA6F609043A04 Alice (partially authenticated, 2/120)

Imported 1 new certificates, updated 0 certificate, 0 certificates unchanged, 0 errors.

Hint: After checking that the certificate EE99C48D11A4BE940569C4B3919EA6F609043A04 really belongs to
      the stated owner, you can mark the certificate as authenticated.  Each stated user ID can be
      marked individually using:

  sq pki link add EE99C48D11A4BE940569C4B3919EA6F609043A04 --userid "<alice@example.com>"

  sq pki link add EE99C48D11A4BE940569C4B3919EA6F609043A04 --userid "Alice"

      Alternatively, all user IDs can be marked as authenticated using:

  sq pki link add EE99C48D11A4BE940569C4B3919EA6F609043A04 --all

Using sq network search this way will:

  • query all default keyservers (keys.openpgp.org, mail-api.proton.me, keys.mailvelope.com, keyserver.ubuntu.com, and sks.pod01.fleetstreetops.com);
  • try to download a certificate via WKD;
  • and query the DNS for a DANE entry.

In this example sq network search found exactly one certificate, and stored it in the local certificate store.

To keep track of the certificate's origin, Sequoia PGP creates intermediate certificate authorities, which certify the received certificate. This is the mechanism by which Sequoia PGP determines implicit authenticity by origin.

Each successful attempt adds 1/120 to the "authenticity value"; in this case, the same certificate was found on two different keyservers, giving it a score of 2/120.

The list of keyservers can be customized by passing --server $URI; this option can be used multiple times:

$ sq network search --server hkps://keys.openpgp.org --server hkps://my.own.keyserver.net alice@example.com

This customization however only affects the list of keyservers; WKD and DANE are still used.

Please note that server addresses passed via --server must also specify their protocol (e.g. hkps://).

Using the --output $FILE option prevents sq from importing the certificate into the cert store, writing it to the supplied $FILE location instead. In this case, sq will also consult the local cert store for matching certificates.

$ sq network search --output alice.cert alice@example.com

sq network search takes a query as parameter. In the examples above, this was a User ID in the form of an email address, but it can also be a fingerprint. This will fetch Alice's certificate from the example above:

$ sq network search EE99C48D11A4BE940569C4B3919EA6F609043A04

Surprising results

When querying network servers for certificates, it's possible that seemingly unrelated certificates are returned. This is especially true for WKD and DANE. sq network search will fetch all these certificates, as they might be usable or be better matches than what was originally requested.

Remember that that fetched certificates are not authenticated automatically, so they will not undermine your security.

Fine-tuning the list of sources for retrieval

sq allows you to restrict the sources it queries for answers:

  • sq network keyserver search
  • sq network wkd search
  • sq network dane search

This will limit the search to the respective sources. Keep in mind that not all sources can deal with all query types: WKD, for instance, can only be queried for User IDs in the form of email addresses.

Authenticating

sq network search will download matching certificates into the cert store. In this state, the certificates are of limited use, as they do not (yet) contain authenticated User ID to certificate bindings; The certificate is treated as unauthenticated. To change this, use sq pki link add to add authentication to bindings. For details see Authenticate certificates.

By the way:

$ sq network search alice@example.com
Note: Created a local CA to record provenance information.
Note: See `sq pki link list --ca` and `sq pki link --help` for more information.

Importing 1 certificate into the certificate store:

  1. EE99C48D11A4BE940569C4B3919EA6F609043A04 Alice (partially authenticated, 2/120)
     ----------------------------------------
     ^- this is the fingerprint