Am 19.05.2014 10:35, schrieb Andreas Tauscher:
Hello!
Maybe somebody can enlighten me.
RFC 3920 says in section 5.1.8:
3920 is obsolete. Refer to 6120 and 6125.
[---- SNIP ----]
As I read this if I have a domain foo.bar an the SRV record points to
im.example.com c2s and s2s has to verify the certificate against foo.bar
instead im.example.com.
Correct.
I can't find out why XMPP should not handle it like SMTP. In case of s2s
the certificate is verified against the canonical name in the MX record
(for XMPP the _xmpp-server._tcp record is like the MX record for SMTP)
and the XMPP _xmpp-client._tcp record I see like autoconfig/autodiscover
for mail.
Because that delegation is not secure (unless dnssec is used).
XMPP I have to create and install a certificate for every domain.
Yes. Well, not to get encryption. Only to get authenticated encryption.
Making it IMHO only complicated and contra productive for enforcing a
full encrypted XMPP network.
No. It makes it complicated to enforce authenticated encryption on the
network. However, we're currently talking about unauthenticated
(opportunistic) encryption which doesn't require certificate checking.
On a mail server I can host thousands of domains with one certificate.
mail servers rarely care about the certificate.
Why do I have to deal in XMPP in this case with thousands of certificates?
This is a known problem.
http://tools.ietf.org/html/draft-ietf-xmpp-dna-05#section-8 explains
that in more detail.
The currently proposed solutions for this are to either use DANE or POSH.
