[Standards] TLS certificate fun
justin-keyword-jabber.093179 at affinix.com
Tue May 13 19:37:39 UTC 2008
On Tuesday 13 May 2008 11:40 am, Dave Cridland wrote:
> On Tue May 13 19:29:33 2008, Justin Karneges wrote:
> > Two sets?
> Yes. One that says "If any xmppAddr is present, use only xmppAddr",
> another that says "but fallback to dNSName". This is okay as long as
> both ends know which identities are authenticated.
3920, section 14.2, case #1 essentially says that if the xmpp field is present
then use it, otherwise fall back to dNSName (and then commonName). Where is
the other set of rules?
> > I'm not sure how you work out a default authzid from a certificate,
> > but
> > assuming there's an unambiguous way to do that then yes this would
> > be fine.
> There isn't, this is highlighting that we need to ensure that an
> authzid is explicitly stated.
Right, so in the context of XMPP, we'd require an authzid when using
> > Yes, a mutually authenticated bidirectional channel. To clarify
> > though, if
> > this is an s2s channel then stanzas can only flow in the
> > initiator->receiver
> > direction.
> Why? If it's mutually authenticated, this seems silly.
I asked the same thing in 2004. :) The stanza direction issue has nothing to
do with mutual authentication. Dialback streams are also mutually
authenticated, and non-stanza traffic can be exchanged bidirectionally. It's
just a historic property of s2s channels to be unidirectional for stanzas.
Maybe this helps with race conditions when two servers contact each other at
the same time, or maybe helps with load balancing (different machines for
outbound/inbound). I dunno. This is just how it is in the spec.
> Drastically so for deployments with significant numbers of
> identities. Two servers with two identities need 4 bidirectional
> channels, or 8 unidirectional channels. Two servers with three
> identities would need 18 unidirectional channels - you need N*M
Oops, you're right. 8 connections for two servers with two identities.
A1->B1, A1->B2, A2->B1, A2->B2, and then the reverse for each.
> > We'd just need a way to specify additional explicit from/to domains
> > on an
> > as-needed basis (exactly like dialback), which also avoids wildcard
> > problems.
> *nods* I think dialback itself will essentially work, the trouble is
> that an originator won't be expecting a dialback initiated by the
> Dialback is an assertion that states "I am this identity". Typically,
> the receiver tests the assertion by dialling back, but realistically,
> nothing stops the receiver testing the assertion by checking a
> certificate associated with the channel.
True. What we'd want to prevent is the receiver actually dialing back though,
since, as you say, the initiator would not be expecting it in a pure-SASL
There could be a stream feature offered by the receiver, that indicates
<db:result> may be used post-TLS/SASL auth for adding more cert-based
identities. Hmmm.. at that point I'd suggest just using a new element
rather than hijacking the dialback ones, to reduce confusion. They are so
More information about the Standards