Kyle Hamilton wrote: > You can have B contact the server and obtain a signed "authorization > certificate" for its key that uses custom extensions to specify 'is > authorized to connect to A' for a given timeframe, and have that be > the certificate that B presents when connecting to A. Then, A looks > for the 'authorized to connect to' list, finds itself in there, checks > validity time, and makes the decision based on that. No need to share > the public keys, nor is there a need to tell both sides about it if > the signature can be verified. > > If you want the server to mediate access between peers without having > to have your clients constantly connected to the server, that's a way > to do it.
Maybe I'm missing something, but it doesn't seem to me like that would work. How does B know it is talking to A? If you expect the "is authorized to connect to" certificate to contain both public keys, then how can you say "no need to share the public keys"? And if not, how does B know it is talking to A and A to B? I'm probably misunderstanding you. But if I can misunderstand it, the OP probably can too. And with respect to the other thread, I agree with you. The level of security should be the highest that doesn't require sacrificing things that are more important than security. Sometimes all you need is to keep out your kid sister, sometimes you have to keep out professional spies financed by a major government. The solutions appropriate to those two extremes are very different. Don't let the fact that you can't feasibly implement a perfect solution keep you from implementing one that is more than good enough. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
