On Fri, Jan 1, 2016 at 3:07 PM, Doug Royer <douglasroyer(_at_)gmail(_dot_)com>
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(_at_)cisco(_dot_)com, 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?).