[Standards] TLS certificate fun
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
> > 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
> > 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
> > - and conference.jabber.org does indeed match one of the
> > certificate's dNSNames. So essentially, it's sort of up to me
> > 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
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
> The receiving entity is authorized as whatever domain was present
> in the
> stream 'to' attribute sent by the initiating entity. This field is
> 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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards