That’s not what I had in mind. I had in mind deliberate attacks on the system by malicious and highly skilled people.
Do a threat analysis—see how your proposed systems holds up under attack from various entities (e.g. (a) script kiddies; (b) a competent black hat; (c) a bunch of competent black hats controlling large botnets; (d) government).
That’s part of why I haven’t gotten very far in fiddling with webfist. I may, in fact, may have to use something else as the basis of the key-exchange protocol—but, like vCard, it already does most of what I want to do, so I’m hoping I can save some time and effort by adapting the existing method instead of starting from scratch.
Looking at what I’m currently doing with vCard from that point of view, it’s already possible to publish a PGP key publicly—see the various keyservers. And if a user wants to use that method, they can have their signed vCard point to it. Signed vCards simply allow for a few more options for key-publication, key-signing, and key-revocation. There doesn’t seem to be any new attack-vectors outside of the ones that already exist; so the main security work is going to be hammering out the key-exchange and -verification protocols. Heck, for that, I could probably even get away with just sending signed-and-encrypted blobs with UUCP or Tor or bluetooth or QR codes, if I set my mind to it. (Traffic analysis of that last one would be something of a pain, requiring analysis of, you know, actual traffic. :) )
In short, I’m not locked into a doomed security model just yet. And as I’m writing this proto-RFC, I’m working on making contacts with enough crypto-type people to have a shot at avoiding building a security system good enough that /I/ can’t break it. (Feel free to point some crypto-geeks or security experts in my direction, if you know any.)
That’s not what I had in mind. I had in mind deliberate attacks on the system by malicious and highly skilled people.
Do a threat analysis—see how your proposed systems holds up under attack from various entities (e.g. (a) script kiddies; (b) a competent black hat; (c) a bunch of competent black hats controlling large botnets; (d) government).
That’s part of why I haven’t gotten very far in fiddling with webfist. I may, in fact, may have to use something else as the basis of the key-exchange protocol—but, like vCard, it already does most of what I want to do, so I’m hoping I can save some time and effort by adapting the existing method instead of starting from scratch.
Looking at what I’m currently doing with vCard from that point of view, it’s already possible to publish a PGP key publicly—see the various keyservers. And if a user wants to use that method, they can have their signed vCard point to it. Signed vCards simply allow for a few more options for key-publication, key-signing, and key-revocation. There doesn’t seem to be any new attack-vectors outside of the ones that already exist; so the main security work is going to be hammering out the key-exchange and -verification protocols. Heck, for that, I could probably even get away with just sending signed-and-encrypted blobs with UUCP or Tor or bluetooth or QR codes, if I set my mind to it. (Traffic analysis of that last one would be something of a pain, requiring analysis of, you know, actual traffic. :) )
In short, I’m not locked into a doomed security model just yet. And as I’m writing this proto-RFC, I’m working on making contacts with enough crypto-type people to have a shot at avoiding building a security system good enough that /I/ can’t break it. (Feel free to point some crypto-geeks or security experts in my direction, if you know any.)