[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