[Standards] XMPP Certificate checking algorithm
justin-keyword-jabber.093179 at affinix.com
Mon Feb 18 00:39:17 UTC 2008
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.
> 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...
More information about the Standards