[Security] TLS Certificates Verification

Dirk Meyer dmeyer at tzi.de
Mon Aug 18 06:39:10 CDT 2008


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

Let's hope more people will join it :)

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

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

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

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

> 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

Not yet, but I will take a deeper look.

> You might be interested in this, too:
> http://www.ietf.org/internet-drafts/draft-groth-openpgp-attribute-extension-00.txt

Again, I will take a look.

Thanks


Dirk

-- 
Smash forehead on keyboard to continue.....


More information about the Security mailing list