Merge remote branch 'mjgoins/master'
[monkeysphere.git] / website / why.mdwn
diff --git a/website/why.mdwn b/website/why.mdwn
deleted file mode 100644 (file)
index d1c15c2..0000000
+++ /dev/null
@@ -1,182 +0,0 @@
-[[!meta title="Why should you be interested in the Monkeysphere?"]]
-
-# Why should you be interested in the Monkeysphere? #
-
-[[!toc levels=2]]
-
-## As an `ssh` user ##
-
-Do you use `ssh` to connect to remote machines?  Are you tired of
-seeing messages like this?
-
-       The authenticity of host 'foo.example.org (192.0.2.3)' can't be established.
-       RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90.
-       Are you sure you want to continue connecting (yes/no)?
-
-Do you actually tediously check the fingerprint against a
-cryptographically-signed message from the admin, or do you just cross
-your fingers and type "yes"?  Do you wish there was a better way to
-verify that the host you are connecting to actually is the host you
-mean to connect to?  Shouldn't our tools be able to figure this out
-automatically?
-
-Do you use `ssh`'s public key authentication for convenience and/or
-added security?  Have you ever worried about what might happen if you
-lost control of your key?  (Or did you have a key that was compromised
-by [the OpenSSL debacle](http://bugs.debian.org/363516)?)  How many
-accounts/machines would you need to clean up to ensure that your old,
-bad key is no longer in use?
-
-Have you ever wished you could phase out an old key and start using a
-new one without having to comb through every single account you have
-ever connected to?
-
-[Get started with the monkeysphere as a user!](/getting-started-user)
-
-## As a system administrator ##
-
-As a system administrator, have you ever tried to re-key an SSH
-server?  How did you communicate the key change to your users?  How
-did you keep them from getting the big scary warning message that the
-host key had changed?
-
-Have you ever wanted to allow a remote colleague key-based access to a
-machine, *without* needing to have a copy of their public key on hand?
-
-Have you ever wanted to be able to add or revoke the ability of a
-user's key to authenticate across an entire infrastructure you manage,
-without touching each host by hand?
-
-[Get started with the monkeysphere as an administrator!](/getting-started-admin)
-
-## What's the connection? ##
-
-All of these issues are related to a lack of a [Public Key
-Infrastructure (or
-PKI)](http://dictionary.die.net/public%20key%20infrastructure) for
-SSH.  A PKI at its core is a mechanism to provide answers to a few
-basic questions:
-
-* Do we know who (or what host) a key actually belongs to?  How do we know?
-* Is the key still valid for use?
-
-Given a clearly stated set of initial assumptions, functional
-cryptographic tools, and a PKI, these questions can be clearly
-answered in an automated fashion.  We should not need to ask humans to
-do complicated, error-prone things (e.g. checking host key
-fingerprints) except in relatively rare situations (e.g. when two
-people meet in person for the first time).
-
-The good news is that this is all possible, and available with free
-tools: welcome to the Monkeysphere!
-
-## Examples ##
-
-Bob is an `ssh` user, and has just been given an account on
-`foo.example.org` by Alice, the `example.org` system administrator,
-who he knows.
-
-Bob already trusts Alice to properly identify all `example.org`
-servers.  Alice already knows who Bob is, and the new machine `foo`
-knows that it can rely on Alice's certifications because Alice is its
-administrator.
-
-Alice can set up the new `bob` account on `foo.example.org` without
-needing to give Bob a new passphrase to remember, and without needing
-to even know Bob's current SSH key.  She simply tells `foo` that `Bob
-<bob@example.net>` should have access to the `bob` account.  The
-Monkeysphere on `foo` then verifies Bob's identity through the OpenPGP
-Web of Trust and automatically add's Bob's SSH key to the
-authorized_keys file for the `bob` account.
-
-Bob's first connection to his new `bob` account on `foo.example.org`
-is seamless, because the Monkeysphere on Bob's computer automatically
-verifies the host key for `foo.example.org` for Bob.  Using the
-Monkeysphere, Bob never has to "accept" an unintelligible host key or
-type a password.
-
-When Bob decides to change the key he uses for SSH authentication, he
-can do so at once: he generates a new key, revokes his old key, and
-publishes these changes to the public keyservers.  The next time he's
-ready to log into `foo.example.org`, it accepts his new key -- and it
-*won't* accept his old key any longer.
-
-The same thing works for Alice when she decides to re-key
-`foo.example.org` (let's say Alice learned that Eve has compromised
-the old key).  Alice generates a new key, revokes the old one,
-publishes the changes, and the next time Bob connects, he connects as
-smoothly as ever.  And if Eve tries to use the old host key to
-masquerade as `foo`, Bob's SSH client will refuse to let him connect!
-
-Alice can even quit as `example.org` system administrator, and revoke
-her certifications of all `example.org` hosts.  As long as Bob knows
-and trusts the new `example.org` system administrator to identify
-hosts in that domain, there's no problem.
-
-## Why OpenPGP? ##
-
-We believe that OpenPGP is the right PKI to use for this project.  It
-allows a very flexible trust model, ranging all over the map, at the
-choice of the user:
-
-* individual per-host certifications by each client (much like the
-  stock OpenSSH behavior), or
-
-* strict centralized Certificate Authorities (much like proposed X.509
-  models), or
-
-* a more human-centric model that recognizes individual differences in
-  ranges of trust and acceptance.
-
-Even if Bob *doesn't* trust Alice to identify *all* `example.org`
-hosts, his first connection to `foo.example.org` should give him more
-than an unintelligible string to accept or reject.  It should also
-give him the information that Alice (and perhaps her colleague
-Charles) have certified the key.  This is far more useful information
-than the current infrastructure allows, and is more meaningful to
-actual humans using these tools than some message like "Certified by
-GloboTrust".
-
-You may also be interested in [some thoughts about alternate PKIs for
-SSH](/similar).
-
-## Philosophy ##
-
-Humans (and
-[monkeys](http://www.scottmccloud.com/comics/mi/mi-17/mi-17.html))
-have the innate capacity to keep track of the identities of only a
-finite number of people. After our social sphere exceeds several dozen
-or several hundred (depending on the individual), our ability to
-remember and distinguish people begins to break down. In other words,
-at a certain point, we can't know for sure that the person we ran into
-in the produce aisle really is the same person who we met at the party
-last week.
-
-For most of us, this limitation has not posed much of a problem in our
-daily, off-line lives.  With the Internet, however, we have an ability
-to interact with vastly larger numbers of people than we had
-before. In addition, on the Internet we lose many of our tricks for
-remembering and identifying people (physical characteristics, sound of
-the voice, etc.).
-
-Fortunately, with online communications we have easy access to tools
-that can help us navigate these problems.
-[OpenPGP](http://en.wikipedia.org/wiki/Openpgp) (a cryptographic
-protocol commonly used for sending signed and encrypted email
-messages) is one such tool. In its simplest form, it allows us to
-sign our communication in such a way that the recipient can verify the
-sender.
-
-OpenPGP goes beyond this simple use to implement a feature known as
-the [web of trust](http://en.wikipedia.org/wiki/Web_of_trust). The web
-of trust allows people who have never met in person to communicate
-with a reasonable degree of certainty that they are who they say they
-are. It works like this: Person A trusts Person B. Person B verifies
-Person C's identity.  Then, Person A can verify Person C's identity
-because of their trust of Person B.
-
-The Monkeyshpere's broader goals are to extend the use of OpenPGP from
-email communications to other activities, such as:
-
- * conclusively identifying the remote server in a remote login session
- * granting access to servers to people we've never directly met