|0.12.0||Feb 3, 2023|
|0.11.1||Jun 21, 2022|
#292 in Email
What is OpenPGP CA?
OpenPGP CA (certification authority) is a tool to handle OpenPGP keys in groups or organizations - it makes the OpenPGP experience of users easier and safer, at the same time.
Imagine this: Carol is the technical expert in her group. The need for protecting the group's communication has come up, and they are thinking about how to improve this. Carol knows about OpenPGP. In fact, she's not only used OpenPGP herself, she's helped out at a few crypto parties. So, she knows: normal users, even those who are worried about their security, have a very hard time using OpenPGP securely; there are too many details to worry about.
This is where OpenPGP CA helps. The members of Carol's group trust her. She is already their sysadmin. So, it is sensible that Carol acts as a certification authority (CA) for her group. This is exactly what OpenPGP CA helps Carol do. Using OpenPGP CA, only Carol has to verify fingerprints. Her users need to be taught to recognize whether a message has been authenticated, and how to make sure encryption is enabled. However, users don't need to validate the fingerprints of their communication partners, because the CA (operated by Carol) performs this task on their behalf. This significantly lowers the threshold to using OpenPGP correctly, which gives Carol and her colleagues a real chance of communicating securely.
Setting up your OpenPGP CA instance
OpenPGP CA is a flexible tool, designed to integrate usefully with a wide range of environments. There are many ways to make OpenPGP CA work for you. Here, we show one typical workflow. Please read our documentation for more details, or talk to us if you're unsure if OpenPGP CA is a good fit for your use case.
Installing OpenPGP CA
To run an OpenPGP CA instance for your organization, first, you need to install the oca tool on your machine.
Initializing your CA
Then you can create an OpenPGP CA instance for your organization:
$ oca -d example.oca ca init --domain example.org softkey
Alternatively you can initialize a CA instance that uses an OpenPGP card hardware security device as its cryptographic backend:
$ oca -d example.oca ca init --domain example.org card
In both cases, during this initialization step, OpenPGP CA creates an
OpenPGP key for your CA.
The key's User ID is set to
email@example.com (you should make sure
that the CA email address is configured in your email setup to forward
mail to you).
-d <filename> specifies where OpenPGP CA will store the
information of the CA. This includes the private OpenPGP key of your CA and the
public keys of members of your organization. In this example, we'll use
example.oca as storage for our CA's data.
Manage user's keys in your CA
Once the CA is set up, users can supply their public keys to Carol, so she can keep track of the group's keys in their OpenPGP CA instance.
Many users will have pre-existing OpenPGP keys that they'll want to keep using, others will make new ones on their own computer (possibly with Carol's guidance).
Alternatively, in some cases it can be appropriate to generate user keys centrally, using OpenPGP CA, but we won't cover this scenario, here.
Let's say Carol wants to import the public keys of her colleagues Alice and
Bob in the CA. She obtains copies of their public keys and temporarily
stores them in the files
Carol can obtain the public keys in any of a number of ways: Alice and Bob
might have handed their keys to Carol on USB storage, sent them to
Carol by email, or Carol might have pulled them from a public keyserver.
However, before proceeding, it's Carol's responsibility to verify the fingerprints of the keys. That is, she needs to make sure the fingerprints of the keys she has obtained match with the keys that Alice and Bob have on their machines. A typical approach is for Carol to meet Alice and Bob and read out and compare the fingerprints. Different organizations will follow different procedures. The main point is that Carol needs to make sure that she didn't obtain the wrong keys (either from a malicious third party - or by making a mistake, such as getting an old key for Bob from a keyserver, for which Bob has lost access to the private key material).
Once Carol has obtained and verified the keys, she can import them into the group's OpenPGP CA instance. The CA will certify user keys (based on Carol's verification), and based on these certifications, everyone else in the organization can rely on getting the correct keys without having to personally verify every single one. Normally, users will only need to verify the CA's key.
To import the keys into the CA, Carol will perform the following steps:
oca -d example.oca user import -e firstname.lastname@example.org --key-file alice.pub oca -d example.oca user import -e email@example.com -e firstname.lastname@example.org --key-file bob.pub
-d example.oca specifies the location of your CA database,
in this example workflow - in your setup, you could configure your CA
database in your environment and omit this parameter)
Note that Carol explicitly provides email addresses for Alice and Bob's keys while importing them.
By specifying these email addresses, Carol instructs the OpenPGP CA
instance to know which email addresses Carol considers to be appropriately
associated with each key.
In this example, Carol instructs the CA to certify (using a digital
signature) that the identity
email@example.com is correctly linked to
the key in
Alice and Bob's keys may contain User IDs that Carol chooses not to certify with the CA. For example because those User IDs specify email addresses that are not relevant for the group's shared objectives. Or because Carol cannot verify those digital identities and thus opts not to certify them.
Simplifying key discovery with WKD
OpenPGP CA can also significantly simplify key discovery: once you manage the keys with OpenPGP CA, you can automatically output the keys to serve as a Web Key Directory (WKD).
To publish your CA as a WKD, you can export all public keys for your domain, like this:
oca -d example.oca wkd export /tmp/wkd/
When you serve the contents of this directory with a webserver under the
openpgpkey.example.org (note that you also need to configure
https), your OpenPGP keys will be conveniently accessible to the general
public. Most client software can retrieve keys from WKD, and will
automatically find your WKD.
Note, however, that this approach only works for keys that have User IDs
in your domain (
example.org, here). Because WKD relies on the domain
name system (DNS) for lookup, you cannot publish keys that only have User
IDs that are external to your domain, via WKD.
Users can rely on a CA for authentication
One major goal of OpenPGP CA is to make it simple for end users to use keys for their main communication partners with confidence - without having to manually verify each key. By relying on a CA, users delegate checking of keys to a party they explicitly trust.
When relying on a CA, users in the group instantly see each other's keys as authenticated - as soon as their OpenPGP implementations obtain copies of other users' keys, they can be certain that they have obtained the correct key.
Users never need to manually check fingerprints of group members anymore (or sign each others' keys). Instead, they rely on Carol performing the verification task for them - and that Carol formalizes the resulting knowledge as certifications by the group's CA.
This means that, for example, Thunderbird/Enigmail will show green header bars for received email from contacts that the OpenPGP CA admin has authenticated. So when Alice gets email from Bob, there is visual confirmation in her email software that the key that Bob used to sign his email has been verified to actually be Bob's key.
Relying on your CA with GnuPG
To take advantage of a CA, users need to obtain and verify the CA's key, and tell their OpenPGP software to rely on that CA. "Relying on a CA" means that users need to issue a trust signature for the CA key - by doing this, they instruct their OpenPGP software that they want to take advantage of certifications that the CA makes.
A user can configure their GnuPG installation to rely on a CA as follows. First, the user retrieves the CA's key via WKD, then they set up a local trust signature (tlsign) and make sure to verify the CA fingerprint they use is correct (they need to get the correct fingerprint from Carol - for example in printed form, or in a phone call):
$ gpg --locate-external-keys --auto-key-locate wkd firstname.lastname@example.org $ gpg --edit-key '1234 5678 9ABC DEF0 1234 5678 9ABC DEF0 1234 5678' gpg> tlsign gpg> 2 gpg> 1 gpg> example.org y gpg> save
(The fingerprint 1234 5678 9ABC DEF0 1234 5678 9ABC DEF0 1234 5678 above needs to be replaced with the correct fingerprint for your CA's key)
example.org as a domain-restriction, we tell our GnuPG
installation to only rely on the CA regarding certifications on identities
in your domain
example.org (depending on the nature of your organization
it might be more appropriate to configure an unconstrained trust signature
Testing authentication based on our CA
Anyone who has configured their OpenPGP environment to rely on our CA as shown above will automatically see our users' keys as "trusted":
$ gpg --locate-external-keys --auto-key-locate wkd email@example.com [..] uid [ full ] Alice <firstname.lastname@example.org> [..]
Federation between organizations that use OpenPGP CA
OpenPGP CA not only makes it easy for users within an organization to authenticate each other, but provides support to create so-called bridges between organizations. In this case, the CA admins from two OpenPGP CA using organizations sign each other's CA key using a scoped trust signature.
See the section on how bridges allow for authentication between organizations in our background documentation for more details.
To get a deeper understanding of the ideas behind OpenPGP CA, you can read our documentation about the background and concepts.
Or you can read our hands on documentation about how to run an OpenPGP CA instance.
End users can read our client documentation to learn how to take advantage of an existing CA.