how to deal with trusted certs in clients

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

http://dcbase.org/wiki/ADC_Proposals_list
Locked
en_dator
Member
Posts: 72
Joined: 01 Apr 2008, 19:24

how to deal with trusted certs in clients

Post by en_dator » 07 Mar 2009, 11:31

I started to think of a method to handle cerificates between clients and hubs as it seems that there currenctly is no such method on development (at least not that I am aware of).

I quickly realised why :) It is not a simple matter to handle keys and certs in a "secure" way and still be userfriendly. I came up with an idea that im pretty sure should work, even if it probably is not the most elegant or efficient solution (thats where you guys/girls come in).

This document is not a draft for a spec, it is more of a working method, how it could look to the dc user behind the client.

I'll start with the client-client part as that is the simplest of the two as there already exists a method of encrypted transfer of files between clients.

What we need is a way to share the certificate with another user, we need a way to keep track of which users we have shared it with, we need a way to identify those users and we need somewhere to store all or part of this information.

Sharing should be rather straightforward, as the certs are only useful between clients with working TLS we can use an established ssl tunnel to transfer the cert similar to how a filelist is transfered except in this case we need some activity from both the users.

I suggest that to initiate the process I start a pm conversation with the user I want to excange certs with, then on the pm tab I select "Trust this user", this sends a message to the other client (similar to msn) and on that client is displayed "User en_dator has given you his trust, do you want to trust him/her". Using pm like this we avoid having popups or any other things possibly blocking, and instead we use excisting methods of communication between users even if I admit it might not be the ideal way. It relies on sending preformatted codes in pm that the clients interpret and act on.

If the other users responds positive, the certs are transferred and stored in the "TLSTrustedCertificatesPath" folder using a similar naming scheme as for filelists, "CID".crt should be okay as the spec says that the CID should be unique.

(Yes - I know it is not necessary for both ends to share their certs in order to have a working connection, but enforcing this makes it easier for us to keep track of who we have sent our own cert's to, as that will be the ones we have certs from ;) )

So here we are now, we have some certs in a folder, and as that mean we have also given those users our own cert we know we have selected to trust those users. That also means as we know who they are we could mark those users in the userlist with a different icon or a different color in all the hubs that they are in.

Doing it like this means we dont have to add more information to favs and/or settings, but instead rely on the certs that are avaliable in the folder. (if a client dev wants to add stuff that gives trusted users different benefits similar to what is avaliable for fav users it shouldnt be hard to implement using this method).

Now there are two more things needed for this to be even close to being called "userfriendly", first is a method to stop trusting another user, and as I said above we enforce both users to have each others cert we simply create a function to delete the cert we have, and dispatch a message (PM) to the other client that we have choosen to no longer trust him, that client in turn should then delete our cert as it is no longer of any use to him. Now if that user tries to download from us and we no longer have his cert the client uses ordinary untrusted ssl transfer method instead of trusted ssl method.

The last item on the list is that if for some reason we create a new certificate (either manually or because we have upgraded the client) we need a method to share this new certificate with our existing trusted users. This must be made automaticly and not rely on the user having to do anything manually. If you implement that by keeping a table somewhere, or simply by renaming the stored certs with a prefix for the users that is not yet updated is something that you programmers can figure out what works better (as long as its 'magic' to the user i dont really care wich :) ).

/1dat

Locked