[Standards] XMPP Certificate checking algorithm

Peter Saint-Andre stpeter at stpeter.im
Fri Mar 21 21:04:49 UTC 2008

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"?

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

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

>    Wildcard name matches could be allowed in (b) and (c).


> ---
> 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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080321/ed6f9148/attachment.bin>

More information about the Standards mailing list