> Right, Gotcha! > > There is one flaw in this design however. > > Peers: > A, B, E > > By this scenario all three peers would be able to communicate, not > just A and B, but also E.
Do you want the server to have to approve A to talk specifically to B? Or do you just want A and B to be able to identify each other and make the decision of whether or not to speak? The scheme, as I described it, will allow A, B, and E, to confirm who they are speaking to. Someone with no identity will be rejected, and E cannot impersonate A or B. Is the idea is that the server must specifically approve the A<->B link? In other words, it's not enough for A to know that it's talking to B and vice versa but each must specifically know that the server has approved its communication with the other? In that case, the server should give either peer a signed object that contains both parties' public keys. Whichever peer has that object can then send it to the other. Each peer can validate the other peer's public key and the object from the server, see a match to both its own key and the other party's key, and approve the connection. This may be needlessly complex. If the server is actually in communication with both A and B at the time, it can simply send each side the other side's IP address, port, and the other side's public key. No need for any special certificates or the like since there's already a secure channel to both peers. In that case, each side simply confirms that the other side knows the secret key corresponding to the public key the server gave it. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
