From: Daniel Kahn Gillmor Date: Tue, 18 Nov 2008 06:30:32 +0000 (-0500) Subject: renaming page about signing host keys. X-Git-Tag: monkeysphere_0.22-1~16 X-Git-Url: https://codewiz.org/gitweb?p=monkeysphere.git;a=commitdiff_plain;h=d89e9293654cfd6330e2aa398768eca0fc8fa621 renaming page about signing host keys. --- diff --git a/website/signing-host-keys.mdwn b/website/signing-host-keys.mdwn new file mode 100644 index 0000000..e0d26a7 --- /dev/null +++ b/website/signing-host-keys.mdwn @@ -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 + sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org + sig! D21739E9 2008-10-29 Daniel Kahn Gillmor + sig! 1CF2D62A 2008-11-16 Micah Anderson + + 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 ()' 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 index e0d26a7..0000000 --- a/website/signing-server-keys.mdwn +++ /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 - sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org - sig! D21739E9 2008-10-29 Daniel Kahn Gillmor - sig! 1CF2D62A 2008-11-16 Micah Anderson - - 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 ()' 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.