On Thu, Dec 29, 2005, WebSpider wrote: > On 12/29/05, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > > > That leaves the possibility of a new node (A') impersonating an existing > > node. > > To avoid that you need to be able to identify nodes securely. > > > > How you do that varies. For HTTPS websites for example the certificate > > contains details of the host name and the CA is implicitly trusted to check > > the validity of the entity claiming to represent that host name before > > issuing > > a certificate. > > Right. Then I guess that is something I need to look at, since I > currently cannot reliably identify a remote node, and therefore seem > to be lacking the public key information to initiate secure > communication. > > Would you happen to know other ways of identifying a remote node, > other than to trust DNS? >
Well the usual way is that you don't trust DNS or anything like that you just use it as a "tentative" means to talk to the host you want to. It only becomes "secure" (for an appropriate value of "secure") when the certificate has been validate and indicates it belongs to the intended host. So you are relying on the issuing authority (CA). In you case (for example) the CA would check that "node A" really was node A before issuing it with a certificate using whatever out of band means it considered appropriate. Then when you connect to node A or node A connects to another node using client authentication the certificate contents show that it really is node A. What you put in the certificate is up to you. Setting a DN component such as CN as "Node A" would be one method for example. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
