Dirk Meyer wrote:
Peter Saint-Andre wrote:
Hi Dirk, thanks for starting a discussion about this.

Let's hope more people will join it :)

So far, so good. :)

certificate. One solution could be to sign the certificate by a CA
everyone knows.
For users whose servers are federated across the open XMPP network,
it's possible that the XMPP ICA could issue client certificates.

Yes, that is solution 1 for this problem. Each user can get a
certificate signed by the XMPP CA. But is that practical. I have not
tried to get a signature for my XMPP server yet, but how hard is it?
Every person who can use an IM client and register for an account
should be able to get a signed certificate. IMHO usability is the main
problem we have to keep in mind when trying to solve this.

Agreed.

I think that obtaining a client certificate from the XMPP ICA would be simpler than obtaining a server certificate. The process for obtaining a server certificate is explained at https://www.xmpp.net/ (I'm offline right now and I don't remember the exact URL) -- it involves requesting a website account at xmpp.net, website admin approval based on access to one of the official email addresses or one of the email addresses in the whois record, then logging into the xmpp.net website to visit a "jump page" from which you can finally access the CA site, etc. By contrast, I think that to obtain a client certificate your client would act on your behalf to interact in-band with an XMPP service at xmpp.net or maybe xmpp.startcom.org, with little or no involvement by the user except to click a big "please generate a security certificate for me" button and probably visit a special URL provided in a message (which message would probably be an x:data form that is specially handled by the client, not a standard message with a human-readable body).

But maybe this is not needed, some sort of web of trust based on
the certificates is also a valid solution.
It would be interesting to experiment with using OpenPGP keys for
TLS, as described in RFC 5018:

http://tools.ietf.org/html/rfc5081

Then we could leverage existing webs of trust.

Yes, OpenGPG support in TLS is one solution. I did not know it became
a standard, only experimental, but still, the last version I saw was
only a draft. The big question here: is this supported? From what I
found out openssl does not support it, gnutls does. We should not use
something that is not supported on some platforms.

As far as I know, only GnuTLS supports the experimental PGP-based TLS ciphers.

Maybe we can add a signing mechanism outside X.509 for XMPP. The
certificates would be self-signed and the user needs to verify the
certificate based on the fingerprint, the JID and an XMPP web of
trust.
So your client would generate even just an RSA/DSA key?

Yes, a key-pair and self-sign to make any TLS library happy. After
that we can create a web of trust outside the ssl library. I don't
know if this will work, but it could.

That seems like perhaps the most reasonable approach, unless we can make it really easy to obtain a client certificate from the XMPP ICA.

BTW, I think we already have webs of trust in a way over XMPP: we
call it the roster. But currently we don't connect the roster items
to keys or other cryptographic information.

I know, but the roster is only the answer to "Who are my friends?" and
SHOULD NOT the answer to "Is this my friend?". When we both use the
same XMPP server and have TLS between clients and server everything is
secure except that the server itself could read my messages. The
reason for us to open a client-to-client stream is that we do not
trust something in the middle. That "something" is the server, there
is nothing else. So we should not ask the server for keys.

Agreed.

But the roster or the server can be used to help our web of trust.

Yes, I think that the roster can help to bootstrap webs of trust. Clearly the roster by itself does not get us all the way because right now it has no cryptographic qualities.

I
could sign your key and upload it to _your_ server somehow. When
a friend of mine receives your key from your self he also gets my
signature knowing that I trust your key.

Aha, I like that idea. We could modify XEP-0189 (which needs some work anyway!) to include signatures of people who trust your key. We would also define a way for me to send "your-key-signed-by-me" to you, so that you can upload my signature to your key node (but your client should not do that if I am not in your roster or you don't have some relationship with me). One attractive aspect of this approach is that if I subscribe to your key node, I would receive notifications whenever you upload a new signature, thus giving people a visible reminder of activity within the WoT.

/psa


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to