[Standards] XMPP Certificate checking algorithm

Shumon Huque shuque at isc.upenn.edu
Mon Feb 18 01:22:27 UTC 2008

On Sun, Feb 17, 2008 at 04:39:17PM -0800, Justin Karneges wrote:
> On Sunday 17 February 2008 2:23 pm, Shumon Huque wrote:
> > 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

Why is it goofy? The problem I'm trying to solve, is that I
want to deploy an SSL/TLS protected XMPP service at the domain 
name "upenn.edu", which hosts many other SSL/TLS protected 
non-XMPP services. And I want to do it in such a way that the
XMPP service cannot use it's X.509 key+certificate to impersonate
any of the other services (either intentionally or as a result
of compromise). RFC 4985 provides a way to do this. And actually,
I think it could potentially be a solution for talk.google.com if 
everyone adopted it.

This is a general problem (although many people don't realize it).
The predominant certification model in the Internet today is to
issue certificates for hostnames. The problem is that a given
host/domain-name may be providing many services, and for proper
compartmentalization of security, there needs to be way to more
granularly specify what entity a certificate is actually for (such 
as a specific service running on a host).

Another security compartmentalization reason one might want 
certificates tied to hostnames and authorized to provide a 
specific service is: if an SRV record points to 50 backend hosts,
then you can revoke the certificate of a single compromised 
host, instead of having to revoke one shared certificate, and 
taking down the whole system. This of course assumes that 
revoking a certificate actually does something in the real
world :-)

In case it wasn't clear, I was proposing this only as an optional
certificate validation method for those organizations that want
to use it.


More information about the Standards mailing list