On Sunday 17 February 2008 2:23 pm, Shumon Huque wrote: > And the current sensible consensus on what to check in the > certificate is: > > 1. If client/server software explicitly specifies the server hostname > to connect to, use that hostname in the certificate check.
I think this is fine as long as the user knows that she is assigning trust to this hostname. If you already have a way to specify an explicit connect hostname in your GUI and you're overloading it for trust, then I'd suggest adding some text nearby to explain how this field is more than just a routing point. Implementation note: be careful with upgrades, where an old field that was assumed to be not trusted becomes suddenly trusted. Another implementation note: in some cases users explicitly specify "localhost" if they want to run their client through a local proxy, such as an ssh tunnel. In that case, you may still want two fields: the hostname the client explicitly connects to (e.g. "localhost"), and the hostname the client intends to communicate with on the other side of the tunnel (e.g. "xmpp.domain.com"). I'm not sure yet if we need text in XMPP-Core about assigning explicit trust. To me this seems more like a general X.509 security issue (or even beyond X.509...). I wonder if there is an existing document we can reference. > 2. If not, use the domain identifier portion of the JID. Yes. > In a later message in the same thread, I brought up the additional > possibility of using RFC 4985 to perform certificate checks: IMO, this is totally goofy. A CA creating such a certificate would need authorization from both the certificate owner and the target service. Maybe this could be useful for some internal organization, but it is probably not very useful on the open internet. RFC 4985 is certainly no solution for talk.google.com, which is what this explicit trust stuff is usually about... -Justin
