[Standards] XMPP Certificate checking algorithm

Shumon Huque shuque at isc.upenn.edu
Mon Feb 18 04:07:06 UTC 2008

On Sun, Feb 17, 2008 at 06:59:53PM -0800, Justin Karneges wrote:
> On Sunday 17 February 2008 5:22 pm, Shumon Huque wrote:
> >
> > 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.

Ah, right. I missed the XmppAddr otherName type in my first reading 
of RFC 3920. Thanks for letting me know about that! Although a more 
generalized solution would be preferable.

I wonder if it's actually used in practice? And are there any
implementations that parse that field for certificate validation

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

I guess that depends on what policies the CA has. We have a central
office that manages all CSR submissions to our commercial CA, with
appropriate vetting. So we could stuff a variety of things into
the subjectAltName extension without any additional authorization
or interaction with the CA. However I'm not sure if the CA will
actually issue certs with such extensions, since I haven't tried

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

Yeah, I agree. RFC 4985 is new, and it will certainly take time to 
figure out if protocols, people, software implementors, and CAs will
actually use it in practice. But I'd be nice to keep the door open for
protocols to use things like this.

If the XmppAddr otherName field is populated, I think we'd definitely
want language in the spec that says the subject CN and other fields
must be left blank (which I don't see in the current RFC). Otherwise 
you may not be able to enforce the constraint on the certificate's


More information about the Standards mailing list