[Security] TLS Certificates Verification

Peter Saint-Andre stpeter at stpeter.im
Fri Aug 15 22:47:24 CDT 2008


Hi Dirk, thanks for starting a discussion about this.

Dirk Meyer wrote:
> Hi,
> 
> For End-to-End XML Streams used by Serverless Messaging and Jingle XML
> Streams we use TLS to secure the connection. When also requesting a
> client certificate, both clients have the TLS certificate from the
> other side. The question is: what does it mean?
> 
> I just want to dump a list of ideas here that are open for discussion
> 
> A certificate is useless if I can not verify the owner of the
> certificate. One solution could be to sign the certificate my 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.

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

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

> You can verify that no man-in-the-middle exists with a simple
> challenge-response and a shared secret/password. It could be possible
> that the secret was exchanged using a different protocol, maybe even a
> personal meeting. Or it can be done in-band on the still-not-verified
> connection: "the key is the name of the bar we met last week".
> Depending on how much security you need, you can do it more or less
> complicated.

Has anyone on this list looked into the Secure Remote Password protocol?

Here are some links:

http://srp.stanford.edu/
http://srp.stanford.edu/whatisit.html
http://srp.stanford.edu/analysis.html
http://srp.stanford.edu/design.html
http://tools.ietf.org/html/rfc2945
http://tools.ietf.org/html/rfc5054

> Now I want to add some extra dependencies to it. I want all my
> applications use different certificates all "set trusted" by the key I
> use as person. Why do I want to do it? Several reasons: one is that I
> may want to chat using my mobile phone. If I loose my mobile phone my
> private key is gone. Not a good solution. In my scenario the key is
> not only used to encrypt my chat messages, it is used to controll
> application on different hosts. If it has a different key I can just
> remove the "I trust that device" information with my real key. It is
> very important for my use case to make it possible to add and remove
> devices individually.
> 
> This all sums up to some basic questions:
> 
> 1. Is the certificate sign by some trusted authority or self-signed?
> 
> 2. If it is self-signed, how do I verify the certificate? 
> 
> 3. If we use a web-of-trust based solution by signing certificates we
>    know, where are the signatures stored? Do I trust the people you
>    trust or do I want to verify the key of everyone?
> 
> 4. How to link a device certificate with the user owning it?
> 
> 5. How can I revoke a certificate to indicate that one or more devices
>    do no longer belong to me?
> 
> These are my initial thoughts, I hope we can get a nice discussion
> started about this.

You might be interested in this, too:

http://www.ietf.org/internet-drafts/draft-groth-openpgp-attribute-extension-00.txt

I'll see if I can invite a few more people onto this list so we can have 
a more productive discussion.

Peter

-------------- 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/20080815/5f479bf8/attachment.bin 


More information about the Security mailing list