[Operators] Obtaining XMPP-enabled certificate for server

Simon Josefsson simon at josefsson.org
Wed Jul 20 09:07:04 UTC 2016

Sam Whited <sam at samwhited.com> writes:

> On Tue, Jul 19, 2016 at 4:53 AM, Simon Josefsson <simon at josefsson.org> wrote:
>> I wonder if people really care about this usage any more -- it does not
>> scale well (all domains have to be encoded in the same cert => big
>> certs) and introduces an indirection which often leaves room for
>> attackers
> I don't understand what problem you're solving by doing this.

The "problem" is that my XMPP server is called 'chat.sjd.se' and should
handle my JID 'simon at josefsson.org'.  Without a cert that binds together
both domains, there is no way to verify that 'chat.sjd.se' is authorized
to serve XMPP for 'josefsson.org'.

> As you said, it's just going to make the certs bigger and
> overcomplicates things. Using the common name works fine and, for
> better or for worse, is just about the only thing supported by any of
> the cheap or free cert providers these days.

Using the common name only works in simplified situations where the XMPP
server sits in the domain of the JIDs it is serving, if I understand
correctly.  So I disagree that "using the common name works fine" as a
generic statement.  To illustrate my point, considering answering this:
what common name would you use for my setup above?

> Just because it's in the RFC doesn't necessarily make it a best
> practice, and I think in this case you're just making more issues and
> work for yourself for no benefit.

I share these concerns -- that's why I wonder if that part of the RFC is
really something people care about these days.  Given the lack of
documentation around using SRV-ID's for XMPP certificates out there, it
seems there is marginal interest in this aspect.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/operators/attachments/20160720/23cbd036/attachment.sig>

More information about the Operators mailing list