[Standards] XMPP Certificate checking algorithm

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Mon Feb 18 02:59:53 UTC 2008

On Sunday 17 February 2008 5:22 pm, Shumon Huque wrote:
> 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...
> 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).

For this you can use an XMPP OtherName field of "upenn.edu" and not use the 
other domain identification fields (DnsName or CommonName).  Now the 
certificate will be XMPP only.  However, I now see what you mean.  RFC 4985 
is a much more generalized solution than requiring every protocol to have a 
special field like XMPP does.

> I think it could potentially be a solution for talk.google.com if
> everyone adopted it.

So Google asks its CA for a talk.google.com certificate that contains 
_xmpp-client.mydomain.com, which it could then present to XMPP clients that 
request the "mydomain.com" domain.  The CA would need to get my authorization 
before making such a certificate (three parties involved in one transaction).  
I think we're far away from having the infrastructure for this.

An easier solution is for me to ask my CA to create a certificate for 
mydomain.com that contains an XMPP field of "mydomain.com" and doesn't use 
the other domain identification fields.  Then I give this certificate (and 
private key) to Google.  Admittedly we don't really have the infrastructure 
for this either, but we are close.  I think the StartCom CA can populate the 
XMPP field if you ask for it.  All it needs to do is leave out the other 
fields and we are there.

> 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).

Indeed.  I didn't realize what you were asking at first.  You're right, it is 
a general problem.  At least XMPP does have a non-general solution.


More information about the Standards mailing list