[Standards] TLS certificate fun

Dave Cridland dave at cridland.net
Tue May 13 20:47:15 UTC 2008

On Tue May 13 20:37:39 2008, Justin Karneges wrote:
> 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?
Hmmm... I suppose you could read that as the method for checking  
certificates, and 6.4.2 as the method for generating them. I think  
both could be a lot clearer, though.

> > > 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
> certificate auth.
Well, you'd want to say that XMPP servers SHOULD supply an explicit  
authorization identifer when using SASL. The mechanism is probably  
immaterial, and SASL has no concept of "certificate auth", nor does  
X.509 have any concept of an authorization identifer. But this is  

> > > 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.
So I see. Section 4.4 in the bis draft. Makes no sense, and in  
particular, we've established and agreed that each peer does  
authenticate with the other.

I suppose the inbound/outbound split might make sense, but I'm not  
convinced - but if it's important, a signalling mechanism might make  
sense. See below.

> > 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
> > directions.
> 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.
Of course, I'm not right in my equation - you need 2*N*M directions,  
or N*M bidirectional channels. So if you have a couple of servers  
with MUC and PubSub services, that's 18 unidirectional channels,  
potentially, between them. Of course, typically, we wouldn't expect  
MUC and PubSub channels to cross-talk, so that's probably only 6, but  
that could very easily change if we get the concept of chaining those  

> > > 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
> > receiver.
> >
> > 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
> case.
> 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
> simple anyway.

*nods* The advantage of dialback is that if the assertion is  
unsupportable by the TLS certificate presented, then there's another  
option to validate it if the recipient of the dialback so chooses.

Okay, so a feature, definitely. You'd need to signal that it was  
supported by the originator, too, so it'd need a "I don't have any  
more identities I want to tell you about" form.

Each identity would need individual positive and negative responses.  
Absence of the feature being negotiated would, presumably, also mean  
that the stream would have to be unidirectional. (Maybe we have an  
explicit signal on this too, so you can setup odd combinations, where  
you say that you'd like to be able to send stanzas for a domain, but  
you can't receive them.).

Question is, is this an <iq/>, a <db:result/>, or is this a new  
element entirely?

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