[Standards] XMPP Certificate checking algorithm

Justin Karneges 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 mailing list