+# Signing a server OpenPGP key #
+
+This page is meant to address the issue of signing server OpenPGP
+keys. Server's are not people (or monkeys), obviously, so the
+circumstances under which one should sign a server key is a big
+different than those under which a person should sign another person's
+key.
+
+
+# Why are signatures on the server key important? #
+
+In order for users to connect to a server in a monkeysphere-enabled
+network, the server key must have *full* validity for the connecting
+user. If the user has not themselves signed the server's key, then
+the server's key can only be valid if other people that the user
+trusts have signed the key.
+
+If only one person has signed the server's key, then the user must
+fully trust the single person who has signed the server 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 server key can also be achieved if the
+server 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. It is much
+more common for users to have marginal trust of other users in the Web
+of Trust. For this reason, it is important to have as many people
+sign the server key as possible.
+
+
+## What information should you have before signing a server key? ##
+
+When signing the key of a person, you want to do two things:
+
+1. verify the identity of the person.
+2. verify that the person is actually in control of the key that you
+are signing.
+
+For a server, you want to do basically the same thing:
+
+1. verify the identity of the server.
+2. verify that the server is actually in control of the key that you
+are signing.
+
+However, with a server, verifying these things is a little trickier.
+
+Verifying that the server 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 server on the web? The identity in this case is
+the fully qualified domain name (FQDN) of the host. Verifying this
+identity amounts to being sure that the host in question really is
+located at that FQDN.
+
+
+## Signing the server key ##
+
+If you are the person (or persons) that actually setup the server and
+configured Monkeysphere and ssh on the server, then clearly you should
+definitely sign the server key right away. When the server is first
+setup, the persons who set it up are the only ones who can actually
+vouch for the server key, so their signatures are necessary to get
+things going. Their signatures are also necessary so that they can
+verify the host key themselves and log into the server via
+monkeysphere-enabled ssh in the future.
+
+If you did not set up the server initially, you do not have an
+accumulated full trust of the person(s) who did, and you do not
+necessarily have console access to the server directly, it's hard to
+confidently verify the server 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 ssh host key directly. But this is usually
+untenable.
+
+However, it is still possible to verify the server identity *and*
+server ownership of the key, even in this case.
+
+
+## Remotely verifying server identify and key possession ##
+
+It is in fact possible to verify the identity and key ownership of a
+server 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 <jamie@mayfirst.org>
+ sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org
+ sig! D21739E9 2008-10-29 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
+ sig! 1CF2D62A 2008-11-16 Micah Anderson <micah@riseup.net>
+
+ 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 `ssh://zimmermann.mayfirst.org`.
+I have therefore verified the identity of zimmermann, and verified
+that zimmermann is in possession of the key in question.
projects / monkeysphere.git / commitdiff