I'm implementing this at the moment, and noticing some aspects of
this that weren't apparent to me before.
There are a grand total of three different subject-alt-names we can
consider, and then the commonname components from the subject, too.
But there's no guidance on which combinations are correct, except
that we never consider the commonName components unless there's
nothing else.
After carefully reading RFC 4985, I think we shouldn't be using
SRVName to identify a remote entity, due to the closing points of its
Section 2.
This leaves id-on-xmppAddr and dNSName. The former is,according to
RFC 3920 Section 14.2, and similar text in Section 15.2 of the bis
draft, always preferred over the latter - ie, if the former exists,
the latter is ignored.
This means, amongst other things, that we cannot identify the XMPP
service responding to conference.jabber.org via the certificate it
presents, since it doesn't include an id-on-xmppAddr of
conference.jabber.org.
But wait, because rfc3920bis does state that, in 6.4.2, servers
SHOULD use a representation where jids MUST be included as a dNSName
- and conference.jabber.org does indeed match one of the
certificate's dNSNames. So essentially, it's sort of up to me whether
I accept its certificate, and what jids I authorize it to use.
However, the jabber.org server doesn't know if the connection it
opens to me has been authenticated as conference.jabber.org,
jabber.org, or both; unless it specifies one or the other in the SASL
EXTERNAL negotiation. - which of course will only tell it if I've
accepted that identity alone.
Moreover, it has no way to communicate to me whether or not it
accepts my certificate - so I don't know if I've authenticated, and
therefore I don't know if I can send anything.
Now, of course, both ends can clearly communicate whether they've
received data with a from JID they don't consider authenticated. The
bad news is that <invalid-from/> is a stream error, and will
therefore close the connection. This is not what one might call fun.
So far, then, this leaves me thinking that the only way to use TLS
and SASL EXTERNAL is to use unidirectional streams, one per domain,
which leaves us worse, in terms of efficiency, than dialback.
This doesn't seem like it should be right, somehow...
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
