Signing a service key using OpenPGP
This page is meant to address the issue of signing OpenPGP-based host/service keys. Machines and services are not people, so the circumstances under which one should sign a service key are different from those under which one should sign another person's key.
Note: this document refers to "services", "servers" and "host". "Services" are things that provide a service, like ssh or https. "Hosts" or "servers" are machines (maybe) that host services. It is important to understand the distinction that keys are associated with services on hosts, and not the other way around.
Why are signatures on service keys important?
In order for users to validate a service (such as an SSH or HTTPS server) in a monkeysphere-enabled network, the service key must have full calculated validity from the perspective of the connecting user. If the user has not themselves signed the service's key, then the service's key can only be valid if other people that the user trusts have signed the key.
If only one person has signed the service key, then the user must fully trust the single person who has signed the key. Full trust should be granted sparingly and with consideration, though, so unless the user knows the server admin very well, they will in general not have full trust of this person.
However, full trust of the host key can also be achieved if the service key has been signed by three or more people that the user has marginal trust of. In other words, three or more marginally trusted signatures equals one fully trusted signature (see our OpenPGP trust models page for more info on this). It is much more common for users to have marginal trust of other users in the Web of Trust. For this reason, it is advisable to have as many people sign the service key as possible.
What information should you have before signing a host key?
Before signing the key of a person, you want to do two things:
- verify the identity of the person.
- verify that the person is actually in control of the key that you are signing.
For a service, you want to do basically the same thing:
- verify the identity of the service.
- verify that the service is actually in control of the key that you are signing.
However, verifying these things for a service is less intuitive than it is for a human.
Verifying that the service in question is in control of the key is, in principle, straightforward. If you are logged on to the machine in question, then you can check directly that the key exists on the system.
What is not so straightforward is what exactly it means to "verify the identity" of a remote service on the internet. The identity in this case is the fully qualified domain name (FQDN) of the service. Verifying this identity amounts to being sure that the service in question really is located at that FQDN.
Signing the service key
If you are the person (or persons) that actually setup the service and configured Monkeysphere on the host, then you should sign the service key as part of that process. When the service is first set up, the administrators who set it up are the only ones who can actually vouch for the service key, so their signatures are necessary to get things going. Their signatures are also necessary so that they can validate the host key themselves.
If you did not set up the service initially, you do not have an accumulated full trust of the person(s) who did, or you do not have console access to the server directly, it's hard to confidently verify the service identity and key ownership. You would like to be able to walk up to the server, log in at the console, and get the fingerprint of the service key directly, but this is usually impossible.
However, it is still possible to verify the service identity and service ownership of the key, even in this case.
Remotely verifying SSH identity and key possession
It is in fact possible to verify the identity and key ownership of an ssh service in one fell swoop with monkeysphere-enabled ssh. Here is the procedure:
Attempt to make a monkeysphere-enabled ssh connection to the host in question. Monkeysphere will check that the ssh host key offered by the host matches the OpenPGP key with the correct host FQDN user ID. If the ssh host key and the OpenPGP key with the correct user ID match, then you will have effectively:
1. verified the host identity, because you actually connected to the host in question, which you know because you:
2. verified the host is in control of the key, because the ssh host key offered by the host matches the OpenPGP key with correct host FQDN user ID.
Here is an example:
servo:~ 0$ ssh zimmermann.mayfirst.org -------------------- Monkeysphere warning ------------------- Monkeysphere found OpenPGP keys for this hostname, but none had full validity. An OpenPGP key matching the ssh key offered by the host was found: pub 2048R/860E8F9C 2008-10-29 [expires: 2009-02-26] uid [marginal] ssh://zimmermann.mayfirst.org sig! 76CC057D 2008-11-15 Jamie McClelland <firstname.lastname@example.org> sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org sig! D21739E9 2008-10-29 Daniel Kahn Gillmor <email@example.com> sig! 1CF2D62A 2008-11-16 Micah Anderson <firstname.lastname@example.org> RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e. -------------------- ssh continues below -------------------- The authenticity of host 'zimmermann.mayfirst.org (<no hostip for proxy command>)' can't be established. RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e. No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. servo:~ 255$
I have attempted to connect to the host zimmermann.mayfirst.org.
zimmermann's host key has only marginal validity for the FQDN user
ID in question, so I am not able to connect. However, the
Monkeysphere has checked that the ssh host key actually does match the
OpenPGP key with the correct user ID
I have therefore verified the identity of zimmermann, and verified
that zimmermann is in possession of the key in question.
Only then can I sign the OpenPGP key for zimmerman, if the above
fingerprint is accurately verified (for example, on the server's
console), or if I trust that
Daniel Kahn Gillmor
Micah Anderson <email@example.com> are
legitimate certifiers for this host.