Hi Gert, Steffan and David I fixed following:
a) doc/keying-material-exporter.txt ( "straightforward" spelling ) b) used spaces instead of tabs in ssl_openssl.c:key_state_export_keying_material() + some minor code cleanups Gert I understand your valid questions and still thinking about some real example with doc/specs based on existing general mechanism and references in doc/keying-material-exporter.txt Best Regards Daniel On 10 March 2015 at 09:08, Gert Doering <g...@greenie.muc.de> wrote: > Hi, > > On Mon, Mar 09, 2015 at 08:46:10PM +0100, daniel kubec wrote: >> It is nothing more then generating same keying material for client and >> server plugins (OPENVPN_PLUGIN_TLS_FINAL callback) >> without the need of transfer that key throught (D)TLS channel and/or app >> layer. > > Why is it so hard to describe a good use case along the lines of what > I described here? > >> On 9 March 2015 at 20:02, Gert Doering <g...@greenie.muc.de> wrote: > [..] >> > No code needed. Just describe the parts that would be needed to make >> > this work - like "on the server, you need a plugin that talks to >> > foobar service to get a blinkenlight, on the client, you need a plugin >> > that uses EKM to make the light blink, via..." > [..] > > > You have written a lot of crypto speak, and added a bit of handwaving why > this is totally useful - but no specific example, how the bits and pieces > have to be combined to make it work. > > Of course, single-sign-on would be extremely great - but I lack the crypto > background (or the imagination) to see how this could be implemented using > EKM - so, please explain it to us. > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany g...@greenie.muc.de > fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
openvpn-rfc5705-doc-v3.patch
Description: Binary data
openvpn-rfc5705-v3.patch
Description: Binary data
