[Standards] XMPP Certificate checking algorithm

Shumon Huque shuque at isc.upenn.edu
Thu Feb 21 20:17:40 UTC 2008


On Thu, Feb 21, 2008 at 10:49:16AM -0700, Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
> > Shumon Huque wrote:
> > 
> >> 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.
> 
> I've had a chance to read RFC 4985 (sometimes travel is a good thing!).
> Here is my understanding...

Thanks!

> According to this spec, a certificate presented by an XMPP service would
> include an SRVName, i.e. an object identifier (OID) of id-on-dnsSRV,
> where the SRVName takes the following form:
> 
> _xmpp.domain

> So what does this mean in practice?
> 
> First let's take Shumon's example of upenn.edu, which resolves via SRV
> to jabber.upenn.edu. In this case, the certificate would include an
> SRVName of _xmpp.jabber.upenn.edu, which would help the connecting
> client (or server) to know that jabber.upenn.edu is the authorized
> domain for connecting to the canonical XMPP service at upenn.edu (e.g.,
> thus knowing that the DNS SRV lookup did not return poisoned results).

Yes, that's precisely right.

> Now let's take another popular example: Google Talk. As I understand it,
> if you connect to gmail.com or googlemail.com or any one of the many
> Google Apps services, you would be presented with a certificate that
> contains an SRVName of _xmpp.talk.google.com; thus you would know that
> this "redirection" is acceptable.

Can someone elaborate on the google talk configuration. What is the
JID domain-name? server hostname? and hostname in the certificate?

> If we go down this path, then:
> 
> 1. I think that we probably want to deprecate use of the id-on-xmppAddr
> OID in server certificates, since the SRVName meets our needs (this
> would not apply to clients).

Yes, I was thinking exactly the same thing.

> 2. I think that we probably want to deprecate use of the dnsName form in
> server certificates.
> 
> 3. I don't think we can tell CAs not to include a Common Name, since
> many CAs probably have a policy that a certificate needs to include a CN
> (as mentioned, I know this is true of StartCom, which is the root CA for
> the XMPP ICA). However, I think we can specify that the relying party
> (connecting client or server) must not treat the CN as a domain name for
> purposes of certificate validation (even if it says something like
> "jabber.org" or "upenn.edu"). In other words, the Common Name should be
> a human-friendly name like "The Jabber.org Project" or "The University
> of Pennsylvania", which is not used for certificate validation.

Well, I think it was pointed out earlier that technically the
IETF has deprecated domain names in the subject DN's "Common Name" 
in favor of the subjectAltName's dNSName. This certainly conflicts
with many existing CA practices and many software implementations.
Nevertheless it seems unwise to me to deprecate domain names in 
dNSName and yet allow them in the common name.

If we are to use RFC 4985, we still need a way to preserve backward
compatibility, as you pointed out earlier. The only way I know to do 
that would be to allow certificates to contain hostnames where current
software expects them (Common-Name or if we're lucky dNSName), and to
allow the subjectAltName SRVName field to be populated.

For my service I'd issue a certificate with:
	subject CN: jabber.upenn.edu
	subectAltName SRVName: _xmpp-client.upenn.edu

Clients oblivious of RFC 4985 would use the old method and try to
validate jabber.upenn.edu. Newer clients would validate RFC4985.

The other reason to have hostnames in certs independently of 
SRVName is to be able to issue different certs to different 
nodes constituting the service.

> Open issue: should wee allow a certificate to contain multiple instances
> of the SRVName? This seems advisable, since the result of an SRV lookup
> can include multiple domain names. In this case, we need to specify the
> matching rules (e.g., if any one domain matches then the relying party
> should consider the certificate to be valid).

Right. I would expect a very common server configuration to use 
the same certificate for c2s and s2s connections. So, it would 
need to have two SRVName fields populated with _xmpp-client.domain 
and _xmpp-server.domain. And if it's providing service to many more
xmpp domains, then correspondingly more fields would be needed if
you're trying to share the certificate across them. The matching rule 
should be based on the service you're using though. If it's an s2s 
connection for domain A, then you'd want to make sure the validated 
cert has a SRVName field specifying _xmpp-server.A.

--Shumon.



More information about the Standards mailing list