[Standards] TLS certificate fun

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Tue May 13 15:38:22 UTC 2008

On Tuesday 13 May 2008 5:50 am, Dave Cridland wrote:
> 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.

Right, we shouldn't use this, since XMPP-Core does not specify that it should 
be used.  But this may change.

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

"Sort of up to me" sounds like there's guesswork.  Compare a jid against the 
certificate according to the rules, and you'll know if it is authorizable.

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

Yes.  I believe authzid is necessary with SASL EXTERNAL.  And yes, you can 
only authorize one identity per TCP connection.

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

The receiving entity is authorized as whatever domain was present in the 
stream 'to' attribute sent by the initiating entity.  This field is optional 
if you plan to use dialback, but required if you plan to use TLS/SASL.

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

Don't need to go there. :)

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

Yep, this is how it is.


More information about the Standards mailing list