> -----Original Message----- > From: Matthias Wimmer [mailto:[EMAIL PROTECTED]
> Hi JD! > > JD Conley schrieb am 2004-11-12 09:18:46: > > > Not sure ... there are valid reasons to change your s2s certificate: > > > > > > - Key expired > > > - Key has been compromised > > > - Key has been lost > > > > > > > Well, if the cert changed you could then "verify" the key again with a > > dialback and reset the cache if you got the same response from the > > dialback authority. > > Allowing dialback to verify new certificates ... I don't think that this > will improve security. It can't be harder than dialback, as an attacker > can always force you to use dialback again (presenting a new > certificate) ... The only thing that changes is, that you get a second > change to take over a host: You get the known certificate of a server. > > So I guess using this approach would be even weaker than pure dialback. Obviously the attacker would get the public certificate of the server they're connecting to. I don't see how having that information is a chance to take over a host. If an attacker attempts to connect and provides a certificate that is not on record for the host they are claiming to be, a dialback is performed against the authority of the host. The attacker, unless they have control of DNS or the other host's network, is then rejected as the dialback authority would produce a certificate that is not the same as the attacker's. > Having a trusted body like the JSF, that acts as a registry/CA might be > a solution and I am looking forward to see Peter's proposal ... the > remaining problem might be to verify if someone is allowed to apply for > a certificate. At this point, I'd rather use dialback on the public internet and let administrators choose which CA's they want to trust. Most of the time CA's are going to be intranet or extranet CA's. Some may choose to trust the "default" trusted set so a VeriSign cert would work, for example. But in the end, with dialback in place, you don't need CA based certificates unless you're setting up a very specific trust network. This is much more user friendly and fairly secure (at least as much as you can trust someone on the internet with no real liability to properly manage a CA). JD _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
