--- /dev/null
+outline for 1 hr seminar talk to CS/security academics
+
+ - key-based authentication is here to stay. (e.g. https, ssh).
+ - host vs. user
+
+ - raises key management/distribution issues
+
+ - what PKIs are available? X.509, OpenPGP, SPKI
+
+ - social vulnerabilities - single-signer vs. multi-signer
+
+ - protocol vulnerabilities - single cert vs. multi-cert (server
+ vs. client again)
+
+ - utility for group-internal work, phased approach to public
+
+
+
+Stream-based communications over the public network have an
+authentication problem. Most data streams are not authenticated in
+either direction, and most of those that are authenticated in at least
+one direction use authentication regimes which suffer from a range of
+known structural problems.
+
+Public-key-based authentication offers security advantages over
+shared-secret approaches, but it introduces additional questions of
+key distribution, binding, and revocation. Two common solutions to
+these problems on today's network are X.509 certificates (used by TLS
+connections like HTTPS) and so-called "key continuity management"
+(KCM) (used by popular SSH implementations and the "security
+exceptions" interface for some web browsers). Both of these schemes
+present security concerns of their own: KCM has trouble with initial
+contact, key revocation, and re-keying; and X.509's single-issuer
+certificate format has a systemic bias that selects for unaccountable
+third-party authorities. New work ("the Monkeysphere") extends the
+OpenPGP Web of Trust into authenticating stream-based communications
+(instead of its traditional message-based environment of e-mails and
+files) by means of a protocol-independent overlay. As a simple,
+alternative PKI, the Monkeysphere resolves these failings, and also
+provides features currently only available as protocol extensions
+(such as SNI).
+
+
projects / monkeysphere.git / blobdiff