[Standards] XMPP Certificate checking algorithm

Shumon Huque shuque at isc.upenn.edu
Sat Mar 22 02:19:06 UTC 2008


On Fri, Mar 21, 2008 at 03:04:49PM -0600, Peter Saint-Andre wrote:
> Shumon Huque wrote:
> > Any comments on the following server certificate checking 
> > algorithm?
> > 
> > 1. (If implementation understands RFC4985) look for RFC4985 style 
> >    service identity in an otherName field (of type OID id-on-dnsSRV). 
> >    The expected identity should be:
> > 
> > 	_xmpp-client.DOMAIN for client-server connections
> > 	_xmpp-server.DOMAIN for server-server connections
> 
> Yes, you're right, it's _xmpp-client and _xmpp-server (not _xmpp).
> > 
> >    where DOMAIN is the JID domain.
> 
> What do you mean by "JID domain"?

Ah, I mean the "domain" in the following ABNF from RFC 3920:

      jid             = [ node "@" ] domain [ "/" resource ]

Also described as the "Domain Identifier" in Section 3.2.

> > 2. Look for expected server identity (either JID domain or 
> >    explicitly configured server hostname) in:
> > 
> > 	a. subjectAltName otherName field of type id-on-xmppAddr
> 
> But I think we deprecate this for servers, so at least it should go
> after your (b).

Sure, that sounds reasonable.

> > 	b. subjectAltName dNSName field
> > 	c. subject DN's Common Name field
> 
> Do we really want to check the CN? It's been deprecated for years.

I included it mainly for backwards compatibility. I'm sure 
there are many (most?) certificates out there that include the
domain name only in the CN. I've seen quite a few other protocol 
specs mention that the use of CN is permitted although discouraged
in favor of dNSName. 3920bis could do something similar.

> >    Wildcard name matches could be allowed in (b) and (c).
> 
> Yes.
> 
> > After seeing Peter's note about the approved sieve notify
> > mechanism, it just occurred to me that another approach to 
> > identify service names might be to use the xmpp uri scheme.
> > Has anyone considered this before?
> 
> I don't think so.
> 
> > In that case, you could just use the subjectAltName's existing 
> > uniformResourceIdentifier field to store JID strings prepended
> > with "xmpp:".
> 
> Back in the old days (RFC 3920) we didn't have an XMPP URI scheme.
> 
> > Are there any advantages to this approach? It seems to have all
> > the functionality of id-on-xmppAddr without needing a special
> > otherName type. It provides the ability to specify client identities
> > which RFC4985 does not, if client certificate based authentication
> > is used. On the other hand, RFC4985 is able to differentiate the
> > c2s and s2s identities, which may be important, and more naturally 
> > maps to their SRV records.
> 
> I think I like the SRV approach better.
> 
> Peter

Yes, I think I like the SRV approach also.

--Shumon.



More information about the Standards mailing list