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