--- /dev/null
+# 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.
+++ /dev/null
-# 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.
projects / monkeysphere.git / commitdiff