renaming page about signing host keys.
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Tue, 18 Nov 2008 06:30:32 +0000 (01:30 -0500)
committerDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Tue, 18 Nov 2008 06:30:32 +0000 (01:30 -0500)
website/signing-host-keys.mdwn [new file with mode: 0644]
website/signing-server-keys.mdwn [deleted file]

diff --git a/website/signing-host-keys.mdwn b/website/signing-host-keys.mdwn
new file mode 100644 (file)
index 0000000..e0d26a7
--- /dev/null
@@ -0,0 +1,128 @@
+# Signing a server OpenPGP key #
+
+This page is meant to address the issue of signing server OpenPGP
+keys.  Servers are not people, so the circumstances under which one
+should sign a server key are different from those under which one
+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* calculated validity from the
+perspective of 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 advisable to have as many people
+sign the server key as possible.
+
+## What information should you have before signing a server key? ##
+
+Before 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 internet?  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.
diff --git a/website/signing-server-keys.mdwn b/website/signing-server-keys.mdwn
deleted file mode 100644 (file)
index e0d26a7..0000000
+++ /dev/null
@@ -1,128 +0,0 @@
-# Signing a server OpenPGP key #
-
-This page is meant to address the issue of signing server OpenPGP
-keys.  Servers are not people, so the circumstances under which one
-should sign a server key are different from those under which one
-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* calculated validity from the
-perspective of 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 advisable to have as many people
-sign the server key as possible.
-
-## What information should you have before signing a server key? ##
-
-Before 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 internet?  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.