[jdev] virtual hosting and certificate checking

Peter Saint-Andre stpeter at jabber.org
Wed Mar 1 12:42:53 CST 2006

Hash: SHA1

RFC 3920 (Section 5.1, point 8) specifies that certificates must be
checked against the hostname provided by the initiating entity (e.g., a
client). Specifically:

 8.  Certificates MUST be checked against the hostname as provided by
     the initiating entity (e.g., a user), not the hostname as
     resolved via the Domain Name System; e.g., if the user specifies
     a hostname of "example.com" but a DNS SRV [SRV] lookup returned
     "im.example.com", the certificate MUST be checked as
     "example.com".  If a JID for any kind of XMPP entity (e.g.,
     client or server) is represented in a certificate, it MUST be
     represented as a UTF8String within an otherName entity inside the
     subjectAltName, using the [ASN.1] Object Identifier
     "id-on-xmppAddr" specified in Section 5.1.1 of this document.

This can be problematic for virtual hosting. Consider the following

- - shakespeare.lit runs an XMPP server.

- - shakespeare.lit hosts XMPP services for denmark.lit, montague.lit,
capulet.lit, etc.

There are two possibilities I can see.

1. Every time shakespeare.lit adds a new virtual host, it needs to
generate a new certificate. This is a real pain because of how
certificates are usually generated (e.g., now William Shakespeare needs
to be a root contact for denmark.lit, montague.lit, etc.).

2. Clients open TCP connections to shakespeare.lit (rather than
denmark.lit etc.) but specify the desired virtual hostname in the 'to'
address of the stream header, then check the certificate presented by
the server as either 'shakespeare.lit' or 'denmark.lit' (etc.).

Option #2 is not explicitly forbidden by RFC 3920 as far as I can see,
because the phrase "the hostname as provided by the initiating entity"
is ambiguous -- it could mean (a) the hostname at which the TCP
connection was opened or (b) the hostname of the stream header's 'to'
address. Naturally we'll need to clarify this in rfc3920bis, but my
question now is: how do existing clients and servers handle this?


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20060301/3cc6b550/attachment-0002.bin>

More information about the JDev mailing list