I recently caught up with the rest of you and saw Moxie's Convergence presentation [on youtube]. I truly hesitate to post here; there have been so many long posts, that any additional ones are likely to result in "tl;dr".
I believe Convergence is... just another PKI, or set of PKIs, with some twists, granted. Imagine that Convergence notaries actually behave like CAs and mint [short-lived] x.509 certs for servers, and that that's what clients see when they talk to a notary(ies). Then the notaries would behave as trust anchors for very shallow (one-level) PKIs. But the main differences vis-a-vis the PKI (laugh) we have now are a) the certs issued would be short-lived, b) the TLS servers and the notaries need not have a business relationship, c) the notaries can each implement a variety of notarization policies. All three of these differences add much value: (a) makes revocation simpler, (b) prevents a conflict of interest, and (c) provides clients with potentially useful choices. Imagine furthermore that the client could ask a TLS server to send the cert chains for their public keys to multiple trust anchors, naming notaries as the desired trust anchors. This costs TLS servers nothing, for they can fetch the alternative certs proactively/asynchronously. This approach solves the Convergence privacy issue completely. OTOH, this approach might have an outsize effect on Convergence's potential business models: if the TLS *severs* fetch the alternate certs from the Convergence notaries, then some notaries could pressure web sites to establish a business relationship with them, thus nullifying benefit Convergence (b) mentioned above. And if TLS servers have no business relationship with the notaries? Who pays for the notaries? I doubt users would... But many notaries might be able to operate at ridiculously low costs (I'm not sure; a notary willing to notarize any site's pubkeys/certs will have to be prepared to do a lot of signing, and caching, which won't be free). And if they can't get revenues from client users nor servers... well, at least they won't have to advertise :) But seriously, who pays? Finally, note that since Convergence is really not too different from a PKI anyways (it could be built on PKIX technologies) why not do the same for DNSSEC? Why, yes, I do believe we could, since, after all, DNSSEC is not unlike a PKI either!. I see two ways to do this: 1) make DNSSEC resolvers able to use many roots, not just one, and then accept answers only when all (or most, or...) lookup paths agree on the same result, but since this requires making changes to clients... maybe a less fully-functional approach 2) based on fake DNSSEC root servers that simply parrot (but, signed with a different pubkey, of course) top-level results from other roots (notaries, the real ones, whatever). Now, back to the value of Convergence. It all depends on what the notaries' policies are. But what possible policies might make a notary that valuable? A notary that merely certifies (heh) that a server has the same pubkey today as yesterday doesn't add too much value, for example. A notary that certifies only a small set of servers' keys, say, only U.S. banks', and thus can afford to do a bit more checking, might add a lot more value, particularly if the sites in question have a business relationship with that notary and the notary has a very small world of customers.... ...This actually gets to something I want to elaborate on in a future post: trade-offs involved in trusted third-party vs. authentication methods with pair-wise credentials. The gist: the larger the universe of peers one can authenticate through a third party (and perhaps transitive trust, thus many third parties), the less security the system provides, whereas using pair-wise methods exclusively results in an explosion of pair-wise credentials to keep track of. If I'm right about this (I'm not sure) then pursuing a set of "federations" with small universe of servers with purposes affine to the federations they are members of, may be the best compromise. Just some thoughts... Please accept my apologies for adding to the amount of traffic on this list at this time. Comments welcomed. Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
