Authenticating certificates

In case you ever want to send an encrypted email to someone, you will need public key material to do the encryption. Public key material is part of a certificate, getting the right material is equivalent to getting the right certificate. Certificates also contain User IDs, claiming that the corresponding user published this certificate and that the public key material within is indeed the right one to use. This suggests that once you know the ID of a user (for instance an email address), identifying the right certificate should be easy.

User IDs however are just claims. Claims which need to be verified before it's advisable to use any public key material. This process of verification is called authentication. This process however is blurry - how much "evidence" do I need to rely on the claimed binding between a user id and the public key material?

In case the intended receiver of my email created and published a certificate, there exists a "right" certificate. Certificates have unique, unambiguous identifiers called fingerprints. In contrast to User IDs, these are not claims but checksums over (some of) the content. Knowing the fingerprint allows to identify a certificate with certainty.

This shifts the problem from identifying the right certificate to identifying the right fingerprint, fingerprints however are much smaller - small enough to for instance print on a business card. The downside of fingerprints is that they are completely unintuitive sequences of characters with high entropy and no redundancy - they have no resemblance with a User ID.

Identifying a certificate - the waterproof way

Assuming that you are certain to have the right fingerprint - lets name it $FPR. Retrieving the corresponding certificate can be done with:

$ sq network search $FPR

This downloads the certificate from sources in the internet and stores it in the local certificate store. More details on retrieving can be found here.

The next step is to tell Sequoia PGP that the binding between a User ID and this certificate is valid. This might come as a surprise as we skip the manual comparison of fingerprints - let sq do the job:

$ sq pki link add --cert $FPR --userid $USER_ID

Since sq network search $FPR retrieved a certificate with that fingerprint, all what is left to do is to verify if this certificate contains the wanted User ID. sq pki link add does that and will return an error, if that User ID is not present (or you made a typo in the fingerprint).

After this step everything is set up to proceed with the encryption of the email.

By the way - you can get the fingerprint of your own key by

$ sq pki list $USER_ID

Identifying a certificate - softer approaches

The scenario in the preceding chapter is a bit idealistic - it assumes that

• you are in possession of the right fingerprint
• the corresponding certificate has been published on a well known server in the internet

Usually circumstances are less optimal. But, however you got the fingerprint (or certificate), this happened in a context which can be taken into account - used as evidence.

If you got a fingerprint printed on a slip of paper handed over by the alleged creator of the corresponding key, there is high evidence that you got the right fingerprint. Same could be said if you got the certificate itself on a usb stick.

Things become less reliable if the fingerprint reached you in an email, especially if that email is not signed. If that email came as response to a request ("Please send me your certificate ...") it adds to it's trustworthiness. If you even know the sender personally this might be another plus.

Some keyservers require an attestation. They send an email to each User ID in a certificate which looks like an email address, containing a link. Clicking that link leads to sending a specific request back to the server which is taken as a confirmation of the authenticity of the User ID - certificate binding. If you get a certificate from such a server you can take this into account.

Some websites publish alongside their contact email address the corresponding fingerprint or even the certificate. Assuming that only a limited number of people are able to modify the content of this website and all of them have honest intentions, this can be taken as evidence of authenticity.

However, all the above examples (and there are many more) are circumstantial. They reflect social relationships, assumptions on integrity and diligence and probably more.

On top of this: Not every email is send in a life or death (or prison) situation. Many of them are quiet mundane, for some it might be even acceptable to send them unencrypted.

All of this makes trade offs a viable option. It affects the amount of evidence one wants to see before relying on a certificate. These trade offs are probably the main way how "authentication" is handled.

Using the result

Once you are willing to rely on a certificate, you have to add a link in the PKI of Sequoia PGP. This enables Sequoia PGP to remember your decision and treat the certificate as authenticated from that moment onward.

Adding a link is done by

$ sq pki link add --cert $FPR --userid $USER_ID

Alternatively to --userid also --email would work. If instead you specify --all, all bindings in the designated certificate will be added.

This command does several things:

It's adding a signature to the certificate. This signature indicates that you consider the binding between the certificate and the User ID authentic. Future invocations of sq (or any other software using Sequoia PGP) will recognize this signature and the implied authenticity. You can see the effect by:

$ sq pki link list --cert-email alice@example.com
 - ┌ 60B00B3173854BA69689B19CCAC5C827BE11485F
   └ "<alice@example.com>"
     - is linked

 - ┌ 60B00B3173854BA69689B19CCAC5C827BE11485F
   └ "Alice"
     - is linked

The key used to generate the signature is not an arbitrary key, but the trust root key located in the certificate store. For details see chapter Shadow CAs.

The above command will also add a trust-depth to the certificate - User ID binding. Using sq pki link add like above the trust depth will be 0, which means that the implied authenticity by the signature does not "spread out" - it's limited to exactly this binding.

A trust depth of 1 means that not only the specific binding is considered authentic, but also all certifications made by this certificate.

If the keyholder of bob@example.com is certain that the binding between a certificate and the User ID alice@example.com is authentic, he/she can certify this binding and publish the result (for details see below). If the binding above (containing bob@example.com) would have a trust depth of 1, the implied authenticity would also cover the binding with alice@example.com. The certificate of bob@example.com would serve as a trust introducer in this case. Please note, that this is completely local and can be undone by retracting the link (see below).

Following this example, a trust depth of 2 would expand the coverage to certifications alice@example.com makes. The trust depth is a counter which indicates how many hops in a certification chain will be covered by the initial assertion of authenticity. The maximum depth is 255.

The above sq pki link add with a trust depth of 1 looks like (note the authorize):

$ sq pki link authorize --depth 1 --cert $FPR --email bob@example.com
...

Certificates can have more than one User ID. Instead of treating each User ID separately - repeating sq pki link add for each of them - you can pass --all at the command line.

$ sq pki link add --cert $FPR --all

Links created by sq pki link add will not expire, this can be changed by using --expiration DATE - DATE can either by in ISO 8601 format (2024-01-01) or a time interval like 3y (3 years).

$ sq pki link add --cert $FPR --all --expiration 3y

Links can be retracted at any point in time. Use

$ sq pki link retract --cert $FPR --email alice@example.com

to retract a specific certificate - User ID binding, or

$ sq pki link retract --cert $FPR --all

as a convenience to remove all links associated with the given certificate.

The existing links within the PKI can be listed by:

$ sq pki link list
 - ┌ 042C3AA73E1566E90FDC31B05C1EA3A3B894010E
   └ "Public Directories"
     - is linked as a partially trusted CA
     - trust amount: 40

 - ┌ 4D735E0D7DDE1B338E05F2B80AF4CE6DF697FB28
   └ "<alice@example.com>"
     - is linked

 - ┌ 4D735E0D7DDE1B338E05F2B80AF4CE6DF697FB28
   └ "Alice"
     - is linked

 - ┌ D4A2E8E858B215BD4E0A775C2904DCFB85ED0E9B
   └ "<bob@example.com>"
     - is linked

 - ┌ D4A2E8E858B215BD4E0A775C2904DCFB85ED0E9B
   └ "Bob"
     - is linked

This example shows a list with 2 certificates, each of them has two User IDs. Additionally the shadow CA for "Public Directories" is displayed.