Added new web page about server key signing.

4 files changed, 144 insertions, 2 deletions

diff --git a/website/doc.mdwn b/website/doc.mdwn
index b60cf28..02b4184 100644
--- a/website/doc.mdwn
+++ b/website/doc.mdwn
@@ -8,6 +8,10 @@
  * Getting started as a [user](/getting-started-user)
  * Getting started as a [server admin](/getting-started-admin)
 
+## Going further ##
+
+ * [Signing server keys](/signing-server-keys)
+
 ## Under the hood ##
 
  * [Developing the monkeysphere](/community)
@@ -15,7 +19,7 @@
 
 ## References ##
 
- * [Initial specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH)
+ * [Initial Monkeysphere specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH)
  * [OpenPGP (RFC 4880)](http://tools.ietf.org/html/rfc4880)
  * [Secure Shell Authentication Protocol (RFC 4252)](http://tools.ietf.org/html/rfc4252)
    * [URI scheme for SSH, RFC draft](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
diff --git a/website/getting-started-admin.mdwn b/website/getting-started-admin.mdwn
index 6c8ad53..1c373ac 100644
--- a/website/getting-started-admin.mdwn
+++ b/website/getting-started-admin.mdwn
@@ -7,6 +7,7 @@ so that your users can have it automatically verified, and you can set
 up your machine to automatically identify connecting users by their
 presence in the OpenPGP web of trust.
 
+
 Server host key publication
 ---------------------------
 To generate and publish a server host key:
@@ -48,6 +49,7 @@ effect.  As with any change to `sshd_config`, be sure to retain an
 existing session to the machine while you test your changes so you
 don't get locked out.
 
+
 Monkeysphere authorized_keys maintenance
 ----------------------------------------
 
diff --git a/website/getting-started-user.mdwn b/website/getting-started-user.mdwn
index 5dcb0d6..9b04edc 100644
--- a/website/getting-started-user.mdwn
+++ b/website/getting-started-user.mdwn
@@ -20,6 +20,7 @@ done with a simple cronjob.  An example of crontab line to do this is:
 
 This would refresh your keychain every day at noon.
 
+
 Install the monkeysphere software on your system
 ------------------------------------------------
 
@@ -31,8 +32,9 @@ installed on your system. If you can't (or don't want to) upgrade to
 GnuTLS 2.6 or later, there are patches for GnuTLS 2.4 available in
 [the Monkeysphere git repo](/community).
 
+
 Keeping your `known_hosts` file in sync with your keyring
------------------------------------------------------------
+---------------------------------------------------------
 
 With your keyring updated, you want to make sure that OpenSSH can
 still see the most recent trusted information about who the various
@@ -47,6 +49,7 @@ key for that host to the `known_hosts` file if one is found.  This
 command could be added to a crontab as well, if desired.
 
 
+
 Using `monkeysphere-ssh-proxycommand`(1)
 ----------------------------------------
 
@@ -91,6 +94,7 @@ If you have more than one secret key, you'll need to specify the key
 you want to add the subkey to on the command line.
 
 
+
 Using your OpenPGP authentication key for SSH
 ---------------------------------------------
 
@@ -105,6 +109,7 @@ you can feed your authentication subkey to your ssh agent by running:
 
 FIXME: using the key with a single ssh connection?
 
+
 Establish trust
 ---------------
 
diff --git a/website/signing-server-keys.mdwn b/website/signing-server-keys.mdwn
new file mode 100644
index 0000000..151f975
--- /dev/null
+++ b/website/signing-server-keys.mdwn
@@ -0,0 +1,131 @@
+# 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.