[Security] TLS Certificates Verification

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 18 21:37:10 CDT 2008

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.


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 

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


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080818/207f83ae/attachment-0001.bin 

More information about the Security mailing list