[Standards] TLS certificate fun

Dave Cridland dave at cridland.net
Tue May 13 16:51:14 UTC 2008

On Tue May 13 16:38:22 2008, Justin Karneges wrote:
> 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.
Sure. Which rules, given that there are two sets in rfc3920bis? And  
how do I know which you're using?

> Yes.  I believe authzid is necessary with SASL EXTERNAL.  And yes,  
> you can
> only authorize one identity per TCP connection.
Ah... Firstly, authzid isn't required for SASL EXTERNAL - you can  
request that the other end uses the default - but it's certainly a  
sensible choice here.  Secondly, this seems like a step down in terms  
of efficiency.

> 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  

Okay, so we assume that the S2S originator authenticates us if it  
continues to use SASL EXTERNAL? That's okay, I suppose - what mildly  
concerns me is that the S2S originator is forced into trusting the  
reciever even if the receiver's certificate is not trustworthy, but I  
can't think of a reason why you'd want to authenticate anyway if that  
meant you weren't happy to receive stanzas.  So yeah, I'll go along  
with this, with some relief.

This gets us as far as a bidirectional channel between identities.

Now, if each server has two identities, both represented in the same  
certificate, then this would mean 4 connections, whereas we currently  
use 2 unidirectional streams. This seems a bit silly, so I was  
wondering how to reduce this.

So consider a server A with two identities A-1 and A-2, contacting a  
server B, which has identities B-1 and B-2. If A uses identity A-1 in  
its SASL EXTERNAL, and addresses streams to B-1, then A and B know  
they have authenicated each other as A-1 and B-1.

It seems logical that if a server A sends a stanza to server B from a  
jid which relates to A-1, to a jid which relates to identity B-2,  
then B can then assume that A will accept stanzas from B-2. This  
really suggests that on connection, both ends could ping the other's  
known identities, so the traffic immediately after A authenticates  
with SASL EXTERNAL to B would be pings from A-1 to B-2, and B-1 to  
A-2, thus reducing the connections to a single bidirectional  

The problem is that any identity that is only matched by the  
certificate using wildcards isn't going to be known to the other side  
- not sure how we might handle that, although using a simple <iq/> to  
ask the other side would work, it'd just need stream features to  
support it, so not be as cleanly backwards compatible.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list