[Adium-devl] Ticket #8787 (XMPP cert checking)

[Shumon Huque]

On Wed, Feb 13, 2008 at 05:36:58PM -0700, Peter Saint-Andre wrote:
> Shumon Huque wrote:
> >>> Perhaps the best compromise is:
> >>>
> >>>   1. If the client software explicitly specifies the server hostname
> >>>      to connect to, use that hostname in the certificate check.
> >>>   2. If not, use the domain identifier portion of the JID.
> >>>
> >>> That way, we could use option (1) and avoid certificate check
> >>> warnings, and satisfy our security concerns.
> >> I think that's what we had agreed to earlier in the thread. The specs
> >> don't say that yet, though.
> > 
> > Excellent. Thanks for clarifying that. It wasn't entirely clear to me 
> > that this consensus had been reached. And it addresses my concerns!
> 
> Super. I'll add that to rfc3920bis in the next version:
> 
> http://tools.ietf.org/html/draft-saintandre-rfc3920bis
> 
> Peter

That sounds great. Thanks!

I've recently discovered another potential solution to this 
problem. In an earlier message, I mentioned that I wasn't aware
of any way to specify a service name in an X.509 certificate. 
But I recently discovered RFC 4985, a standards-track document 
from the IETF PKIX working group, which is a specification to 
do just that:

    http://www.ietf.org/rfc/rfc4985.txt

The idea is that the service name is inserted in the otherName
field of the subjectAltName extension. Using this, our certificate
for "jabber.upenn.edu" could then have two instances of the
otherName field of type SRVName for _xmpp-client.upenn.edu
and _xmpp_server.upenn.edu. Thus, the CA is certifying that the 
certificate belongs to host "jabber.upenn.edu" AND that this host 
is authorized to offer the services _xmpp-{client,server} for the 
domain "upenn.edu". This certificate could then be trusted 
without explicit client configuration of the server's hostname
regardless of whether the resolution of DNS SRV records is 
trusted or not.

Obviously the problem with this approach is that it's new and
most likely virtually unused in the SSL/TLS world today. Client/
server software would need to be updated to use it, and some
commercial CA's may have to agree to issue certificates with such 
extensions. But since the XMPP specs are being revised, it might
be a good idea to mention this as an optional method of certificate 
validation, so that the protocol does not prohibit it's use.

Any thoughts?
---
Shumon Huque				3401 Walnut Street, Suite 221A,
Network Engineering			Philadelphia, PA 19104-6228, USA.
Information Systems & Computing		(215)898-2477, (215)898-9348 (Fax)
University of Pennsylvania / MAGPI.	E-mail: shuque -at- isc.upenn.edu