... | @@ -8,7 +8,7 @@ Released date: Possibly end of March 2015 (depending on nettle 3.1 release) |
... | @@ -8,7 +8,7 @@ Released date: Possibly end of March 2015 (depending on nettle 3.1 release) |
|
|
|
|
|
* [x] **System-keys API:** Provide an API to access keys from the system storage, if available. That should, as first step, allow accessing keys from windows key store (and also windows supported smart cards). [The current API design.](https://gitorious.org/gnutls/gnutls/source/91472921689d799cb991db84af7e04fba6b049f1:lib/includes/gnutls/system-keys.h)
|
|
* [x] **System-keys API:** Provide an API to access keys from the system storage, if available. That should, as first step, allow accessing keys from windows key store (and also windows supported smart cards). [The current API design.](https://gitorious.org/gnutls/gnutls/source/91472921689d799cb991db84af7e04fba6b049f1:lib/includes/gnutls/system-keys.h)
|
|
|
|
|
|
* [#] **Privilege separation for private key operations:** During the development of openconnect vpn server, we realized the need for separating private key operations for typical SSL operations. That resulted in ocserv to a special security module that handles the private key operations of a less privileged worker process. That could be generalized so that more applications can use it. The advantage of such a design is that a bug on the TLS/ASN.1 parsing code would not leak the server's private key (thus counter heartbleed type of attacks). That part would be restricted to UNIX/POSIX systems so it may be released as a different library. **This most likely will be [part of p11-kit](http://lists.freedesktop.org/archives/p11-glue/2014-December/000523.html) and will allow isolating PKCS #11 modules**.
|
|
* [#] **Privilege separation for private key operations:** During the development of openconnect vpn server, we realized the need for separating private key operations for typical SSL operations. That resulted in ocserv to a special security module that handles the private key operations of a less privileged worker process. That could be generalized so that more applications can use it. The advantage of such a design is that a bug on the TLS/ASN.1 parsing code would not leak the server's private key (thus counter heartbleed type of attacks). That part would be restricted to UNIX/POSIX systems so it may be released as a different library. **This most likely will be based on some external solution, like [caml-crush](https://github.com/ANSSI-FR/caml-crush) or [p11-kit](http://lists.freedesktop.org/archives/p11-glue/2014-December/000523.html) both based on PKCS #11 modules**.
|
|
|
|
|
|
* [x] **Transparent support for internationalized DNS names:** Add support for [RFC6125 recommendations](https://tools.ietf.org/html/rfc6125#section-6.4.2).
|
|
* [x] **Transparent support for internationalized DNS names:** Add support for [RFC6125 recommendations](https://tools.ietf.org/html/rfc6125#section-6.4.2).
|
|
|
|
|
... | | ... | |