Hi,
On Wed, Nov 1, 2017 at 2:18 PM, Steffan Karger <stef...@karger.me> wrote:
> Hi,
>
> On 29-10-17 22:03, Selva wrote:
> > I would like to see new features transparently supported on Windows
> > as well without the need for too much extra code and associated
> > maintenance burden. Our 'cryptoapicert' implementation is already in
> > need of a major re-write to support TLS 1.2 and newer.
>
> Fully agree. Since cryptoapicert is windows-specific, I actually think
> it would be better to add a 'CNG'[0] implementation to the windows
> wrapper, and make that use management-external-key. That would probably
> improve UX a lot too, showing users a drop-down to select a key, etc.
> We can then remove the whole deprecated cryptoapi implementation from
> the openvpn core.
>
> > From that point of view, instead of file-based wrapped keys, if a pkcs11
> > compatible API can be used to access TPM (that's possible isn't it?) TPM
> > could be more widely usable without the need of any additional support
> > in openssl or openvpn.
>
> Since this one is transparent, and works as long as the user loads the
> right engine, I don't see any limitations to include this patch.
>
Agreed this is a simple patch that could be used right away. Let's address
'Cryptography Next Gen' (CNG) and general use of management-external-key
as a separate topic.
I too feel the management interface client and/or plugins is a better place
to add support for platform specific cert/key storage etc., instead of
polluting
openvpn core.
Simon was planning to add support for TLS 1.2+ in eduVPN for keys
stored in Windows certstore -- I suppose that would involve CNG.
Selva
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
