--- /dev/null
+The Monkeysphere uses the OpenPGP web of trust to provide a
+distributed Public Key Infrastructure (PKI) for users and
+administrators of ssh. This talk is about why the Monkeysphere is
+useful, how it works, and how you can use it to ease your workload and
+automatically fully authenticate people and servers.
+
+The Secure Shell protocol has offered public-key-based mutual
+authentication since its inception, but popular implementations offer
+no formalized public key infrastructure. This means there is no
+straightforward, computable method to to signal re-keying events, key
+revocations, or even basic key-to-identity binding (e.g. "host
+foo.example.org has key X"). As a result, dealing with host keys is
+usually a manual process with the possibility of tedium, room for
+error, difficulty of maintenance, or users and administrators simply
+ignoring or skipping baseline cryptographic precautions.
+
+The OpenPGP specification offers a robust public key infrastructure
+that has traditionally only been used for e-mail and for encrypted
+storage. By its nature, the OpenPGP Web of Trust (WoT) is a
+distributed system, with no intrinsic chokepoints or global
+authorities. And the global key distribution network provides
+commonly-held, public infrastructure for rapid distribution of key
+changes, revocations, and identity binding.
+
+The Monkeysphere mixes the two to provide new functionality for ssh
+(key revocation, key expiry, re-keying, fewer unintelligible prompts,
+semantic authorization, etc) while taking advantage of existing but
+often-unused functionality in OpenPGP. Additionally, the Monkeysphere
+implementation does not require any patches to OpenSSH on the client
+or server, but takes advantage of existing hooks, which makes it easy
+to adopt.
+
+Specifically, the Monkeysphere allows users to automatically validate
+ssh host keys through the Web of Trust, and it allows servers to
+identify authorized users through the Web of Trust. Users decide
+which certifications in the Web of Trust they put stock in (so they
+are not spoofed by spurious certifications of host keys). Server
+administrators decide whose certifications the server should put stock
+in (so that the server is not spoofed by spurious certifications of
+user keys).
+
+This presentation will go over how the Monkeysphere works; how you can
+use it to increase the security of servers you maintain; how you can
+use it to increase the security of accounts you connect to with ssh;
+and we'll discuss future possibilities lurking in the ideas of the
+Monkeysphere.
+
+Monkeysphere is currently available in the main Debian repository and
+as a port in FreeBSD. A Slackbuild is available for Slackware, and
+Monkeysphere itself should work on any POSIX-ish system with the
+appropriate dependencies available.
+
+The project's main web site is http://web.monkeysphere.info/
+
--- /dev/null
+
+
+
+The presentation is in three parts:
+
+Background
+----------
+
+ * Why authentication using asymmetric crypto (as opposed to shared
+ secrets) is important on today's network.
+
+ * Overview of how ssh uses asymmetric crypto authentication (user ->
+ host, host -> user)
+
+ * Overview of relevant bits of OpenPGP (key -> User ID bindings,
+ certifications, usage flags, key -> subkey bindings)
+
+ * Overview of keyservers (the idea of gossip, One Big Network,
+ propagation, issues around redundancy, logging, private access)
+
+
+How
+---
+
+ * How does the monkeysphere do it? (very brief under-the-hood)
+
+ * How does a server administrator publish a host's ssh key to the Web
+ of Trust? How do they maintain it?
+
+ * How does a user incorporate WoT-based host-key checking into their
+ regular ssh usage?
+
+ * How does a user publish their own ssh identity to the WoT for hosts
+ to find it? How do they maintain it?
+
+ * How does a server administrator tell a server to admit certain
+ people (as identified by the WoT) to certain accounts? How do they
+ tell the server which certifications are trustworthy?
+
+Possible Futures
+----------------
+
+ * Use the Monkeysphere with ssh implementations other than OpenSSH
+ (dropbear, lsh, putty, etc)
+
+ * Expansion of the Monkeysphere's out-of-band PKI mechanism for
+ authentication in protocols other than SSH (TLS, HTTPS) without
+ protocol modification.
+
+ * Use of OpenPGP certificates directly in SSH. OpenPGP is referenced
+ in RFC 4253 already: optional, rarely implemented, and deliberately
+ ambiguous about how to calculate key->identity bindings.
+
+ * Use of OpenPGP certificates for authentication directly in
+ protocols. RFC 5081 provides a mechanism for OpenPGP certificates
+ in TLS, but is similarly ambiguous about certificate verification.
+
+ * Better end-user control over verification: Who or what are you
+ really connecting to? How do you know? How can this information
+ be effectively and intuitively displayed to a typical user?
+
+ * What would you like to see?