[Standards] TLS certificate fun

Dave Cridland dave at cridland.net
Tue May 13 12:50:14 UTC 2008


I'm implementing this at the moment, and noticing some aspects of  
this that weren't apparent to me before.

There are a grand total of three different subject-alt-names we can  
consider, and then the commonname components from the subject, too.  
But there's no guidance on which combinations are correct, except  
that we never consider the commonName components unless there's  
nothing else.

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.

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.

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.

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.

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.

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.

This doesn't seem like it should be right, somehow...

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