[Operators] WoT for XMPP servers?

Phil Pennock xmpp-operators+phil at spodhuis.org
Wed Feb 6 23:11:05 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

I'm new to the list and wanted to keep quiet for a while before
commenting, but this is about a topic dear to me, so I'm speaking up.
Since I have no standing in this community, I'll not be surprised if I'm
told I'm an idiot or somesuch.

On 2013-02-06 at 15:32 -0700, Peter Saint-Andre wrote:
> At FOSDEM last weekend, I talked with Bdale Garbee of the FreedomBox
> project. It seems they will be using OpenPGP keys to build a web of
> trust among FreedomBox instances.

What, and you couldn't sign each others keys at the same time so that I
could get a trust path to your key?  ;)  Seriously, the WoT includes
many small linkages, not just large nexuses (nexi?) from key-signing
parties.

> similar could work quite well for the XMPP network (instead of or in
> addition to CA-issued X.509 certificates). Unfortunately, right now I
> think only GnuTLS supports RFC 6019 ("Using OpenPGP Keys for Transport
> Layer Security (TLS) Authentication"). However, it might still be good
> to more widely use OpenPGP keys among XMPP server administrators
> (e.g., have keysigning events at the XMPP Summit and local/regional
> events), and potentially server administrators could sign the
> certificates issued to servers (e.g., I would PGP-sign the X.509
> certificate for the jabber.org server).

This works well in practice as a distribution mechanism for CAs (eg,
I've been able to verify a LIR CA using PGP) but PGP signing of
individual server certificates does not scale to a federated system, and
evaluation of trust paths is significant enough, with enough questions,
to also not scale for PGP as the in-path crypto layer: there, I believe
OpenPGP works when you effectively designate a PGP key as a certificate
authority and require it to have directly signed the keys used for
client auth by those connecting to you.

Unless you're proposing having a well-known derivable URL for fetching a
copy of a detached signature on the SSL cert (or doing it with an XMPP
feature extension) to be able to update trust paths in batch, out of the
main signalling path, to be able to "lock in" previously-unverified
server certs, this is really only going to help for manually maintained
trust paths, which might help between friends or between large
providers, but not for _mutual_ trust across the system as a whole.

Now, off-line verification to lock in, or pin, server certs might be
worthwhile; it would be the XMPP equivalent of cert pinning in web
browsers, with PGP as the trust path mechanism.

> Is anyone else here interested in strengthening the web of trust among
> XMPP server admnistrators (and XMPP servers)?

Always good in general; but frankly, if you want a WoT for SSL right
now, you might as well use CACert, who use a WoT model for identity
assurance but still issue certs centrally.  It's not in browser trust
chains, but if you're after a WoT model it makes a lot of sense to use
it for server-server federated trust.

I believe this has come up before and some folks are opposed to trusting
anything not sanctioned by Mozilla or one of the other mechanisms, with
audits and quality controls.  Frankly, I view CACert as "a better
managed personal CA, which others are more likely to be able to trust".

Did you have any concrete proposals for _how_ to strengthen the web of
trust?  I suspect the closest you can do, absent conferences for XMPP
operators to meet, is to provide technical incentives for folks to take
part, such as an XMPP-feature-based cert-pinning mechanism using PGP for
trust paths, described above, and then let server operators find
incentives to bother attending PGP keysigning parties at other
conferences.

- -Phil
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlES4wEACgkQQDBDFTkDY38L3ACcDccO7fcktB08CJF1nvjo+vIo
VRoAn309N1UoZn3Kmh1dDcs4a2XVGRo3
=GP0p
-----END PGP SIGNATURE-----


More information about the Operators mailing list