[Security] TLS Certificates Verification

David Banes david at banes.org
Mon Aug 18 06:48:06 CDT 2008


I'll hover here and chip in, we went through all of this with  
CipherIM our proprietary Im client in the late 90's 'til 2001.

We did end up generating a key pair at client install time (including  
testing password strength with a little feedback 'progress bar' ) and  
then storing the public part of our keys on the client domains  
server. It all worked fine. We setup SSL client -> server, then  
generated a one time symmetric key for each session.

I did write all this up earlier, happy to re-post if I can find it.

David.
		
On 18/08/2008, at 9:39 PM, Dirk Meyer wrote:

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


------------------------------------------------------------------------------------------------
Email Security by Cleartext a CO2 Free company - www.cleartext.net
------------------------------------------------------------------------------------------------


More information about the Security mailing list