On Fri, Jan 1, 2016 at 3:07 PM, Doug Royer <douglasroyer@xxxxxxxxx> wrote: > On 12/31/2015 10:00 PM, Phillip Hallam-Baker wrote: > >> ... >> I have released the code: >> http://sourceforge.net/projects/mathematicalmesh/ >> > > For those wanting to build the code, it looks as if you need at least VS > 2012 with framework 4.6. Not having build MS code for while, I had 4.5 - > updating. > > Its in C#. Since it is open source code, contributors can use Visual Studio 2015 Community edition free of charge. Or at least that is my understanding of the license. https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx The point of this release is to prove that what I show in the demonstration is actually feasible and has been implemented. This is not production code. The reason for moving to .Net 4.6 is that Microsoft is currently in the process of releasing .Net Core on Linux and OSX. I took the gamble early on that this would happen and so I could use C# for all the code development. Which is a big advantage when you use as many code generators as I do. Now I have not actually run the code on Linux or OSX yet, but it does pass the tests in the compatibility checking tools. The code does make use of some, OK a lot of build tools. These are also open source and available on SourceForge. BUT, probably best to wait a couple of days since I am currently getting to grips with the VSIX packaging tools that make installing and using custom tools a LOT easier. I am just writing a tool that will generate the packaging code bindings. The build tools also generate text for the documentation. Hence when I finally get an Internet draft out, the text in the draft, the examples and the reference code should all be in sync. There is also a limitation in that the current code does not have the DNS library linked in (oops forgot!) so right now the IP address of the service is hardcoded. Will fix that after doing the demos. I have a DNS parsing/generating library but have not added that to this project base yet. The client should discover the service via SRV lookup. This particular release has code that will automatically configure the S/MIME config in Windows Live Mail to use a self signed certificate generated by the toolset. Comodo Group currently issues free S/MIME certs and we are working on a way to get a free CA issued cert using the tool in the very near future. This is NOT a simply scheme to get people to use CA issued keys rather than PGP or SSH however. I have written on this at length: The short is that we need both a hierarchical and a web of trust based infrastructure to meet all of our user-account trust needs. If I am writing to Fred in his IETF capacity, I want to use an encryption key that I trust for Fred. But If I am configuring my GIT repository to receive code from Fred@xxxxxxxxx, it is absolutely essential that the code is endorsed by the Cisco trust chain and not just my personal relationship with Fred. People will obviously want support for OpenPGP as well. But that is not my immediate priority because the point of this code is to show what can be done, if we can take a legacy application like Windows Live Mail and enable the crypto in that without the need for any sort of plug-in, we can obviously use the Mesh for OpenPGP. They way I would want to support OpenPGP is to extend the OpenPGP libraries to include the ability to import/export keys using the Mesh. In the short term, a tool to manage SSH keys using the mesh is going to be a lot more useful to a lot more people. Yes, people have 'ways' to manage SSH keys today but the instructions people are being given to follow are of the 'how to make this work' type, not 'how to be safe'. More than half the instructions I found telling people how to configure SSH keys for GIT left the private key sitting unencrypted on a world readable directory. Using the Mesh to move keys around means that we can build best security practices into the protocol. Keys are automatically encrypted during transport and are only ever decrypted on the target device. Every device has a separate key set, etc. The reason for targeting SSH is also that is the highest leverage point right now. As far as IETF is concerned, SSH is a terminal protocol. But right now, the SSH key infrastructure is what is underpinning the production of most source code, either in GIT (or SVN I presume?).