... | ... | @@ -8,7 +8,7 @@ Target date: mid-April 2015 |
|
|
|
|
|
* [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://gitlab.com/gnutls/gnutls/blob/master/lib/includes/gnutls/system-keys.h#L27)
|
|
|
|
|
|
* [#] **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 are based on PKCS #11 which is well supported**.
|
|
|
* [#] **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, and thus counter heartbleed type of attacks. In plain english, this approach will avoid putting all the eggs in the same basket for a software application. **While the original plan was to support privilege separation within GnuTLS, further investigation shows that this is not necessary. There are fine projects like [caml-crush](https://github.com/ANSSI-FR/caml-crush) which provide isolation for PKCS #11 modules like [softhsm](https://www.opendnssec.org/softhsm/), protecting the same types of attacks we intended to. For that reason, and the fact that PKCS #11 support is integrated into GnuTLS, we recommend to application writers to consider solutions like [caml-crush](https://github.com/ANSSI-FR/caml-crush), and use isolation to protect sensitive keys.**.
|
|
|
|
|
|
* [x] **Transparent support for internationalized DNS names:** Add support for [RFC6125 recommendations](https://tools.ietf.org/html/rfc6125#section-6.4.2).
|
|
|
|
... | ... | |