Heyaz. I've been thinking about Kaboodle's VPN capabilities
recently, and I wanted to write down some ideas I had, see what
anyone thought of them.

        Right now, to enable Kaboodle VPN capabilities, a user
*must* go and register at the GetEngaged website. This process
creates a pub-priv keypair, signs that keypair, and lets the
user download it into a "registration file". That files lands
into the PC with a .ecf extension, an extension registered to
the GetEngaged.exe (aka, EFHelper.exe) application. So when you
double-click on the registration file, the GetEngaged.exe app
checks the signature, and installs the pub-priv key pair if
everything's kosher.

        Same thing is done for every partnership. That is, the
user goes to the website, tells who they want to partnership
with, and the server distributes public keys, again in a signed
file. GetEngaged.exe also handles these files, once they're
downloaded.

        Here's what bugs me: the server has everyones keys, both
public and private. That can't be a good idea.

        In a conversation with Igor Sharov (whom I hope joins this
list) he suggested an alternative. Kaboodle could create it's own
pub-priv key pairs, without server intervention. Further, it could
create a "partnership file" that's password secured, which could
simply be emailed to a partner. If your partner gets the email,
and answers with the right password when GetEngaged asks for it,
it's arguably a more secure situation. Kaboodle could utilize a
"malito:" URL to automatically invoke the user's email program
to make this process close to foolproof.

        I think I can still tie this in with the partner detection
code. That's currently done with a "partnership tag" that's part
of the downloaded partnership files.

        Anyhow. Comments welcome on this.

cheers,
Scott



_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel

Reply via email to