summaryrefslogtreecommitdiff
path: root/doc/conferences/lca2010/outline
blob: 15c486887959b3e7ab32f58da5ad134c2cb2ab9b (plain)
  1. The presentation is in three parts:
  2. Background
  3. ----------
  4. * Why authentication using asymmetric crypto (as opposed to shared
  5. secrets) is important on today's network.
  6. * Overview of how ssh uses asymmetric crypto authentication (user ->
  7. host, host -> user)
  8. * Overview of relevant bits of OpenPGP (key -> User ID bindings,
  9. certifications, usage flags, key -> subkey bindings)
  10. * Overview of keyservers (the idea of gossip, One Big Network,
  11. propagation, issues around redundancy, logging, private access)
  12. How
  13. ---
  14. * How does the monkeysphere do it? (very brief under-the-hood)
  15. * How does a server administrator publish a host's ssh key to the Web
  16. of Trust? How do they maintain it?
  17. * How does a user incorporate WoT-based host-key checking into their
  18. regular ssh usage?
  19. * How does a user publish their own ssh identity to the WoT for hosts
  20. to find it? How do they maintain it?
  21. * How does a server administrator tell a server to admit certain
  22. people (as identified by the WoT) to certain accounts? How do they
  23. tell the server which certifications are trustworthy?
  24. Possible Futures
  25. ----------------
  26. * Use the Monkeysphere with ssh implementations other than OpenSSH
  27. (dropbear, lsh, putty, etc)
  28. * Expansion of the Monkeysphere's out-of-band PKI mechanism for
  29. authentication in protocols other than SSH (TLS, HTTPS) without
  30. protocol modification.
  31. * Use of OpenPGP certificates directly in SSH. OpenPGP is referenced
  32. in RFC 4253 already: optional, rarely implemented, and deliberately
  33. ambiguous about how to calculate key->identity bindings.
  34. * Use of OpenPGP certificates for authentication directly in
  35. protocols. RFC 5081 provides a mechanism for OpenPGP certificates
  36. in TLS, but is similarly ambiguous about certificate verification.
  37. * Better end-user control over verification: Who or what are you
  38. really connecting to? How do you know? How can this information
  39. be effectively and intuitively displayed to a typical user?
  40. * What would you like to see?