[Help-gnutls] Re: Using encrypted keys

[Simon Josefsson]

"Rich Fought" <whatever at fsrz.net> writes:

> So far in my project I have been using decrypted server keys and
> gnutls_certificate_set_x509_key_file to read them (along with the cert) into
> the credentials structure.
>  
> Now I wish to transition to encrypted keys.  From the documentation here's
> what I think I need to do, please let me know if there is an easier or
> different way:
>  
> - Since gnutls_certificate_set_x509_key_file does not support encrypted
> keys, I have to read the encrypted key contents into memory and use
> gnutls_x509_privkey_import_pkcs8 to get they key into the decrypted
> gnutls_x509_privkey type.  (Since I am using OpenSSL to generate my keys, I
> will have to convert to PKCS8 with PKCS12 encryption first.)
>  
> - I then need to read the certificate contents into memory and use
> gnutls_x509_crt_import to get it into the gnutls_x509_crt type.
>  
> - I then need to use gnutls_certificate_set_x509_key to store the imported
> cert/key into the credentials structure.
>  
> Sound right?  The reason I ask is that I need to write Haskell bindings for
> these functions and would rather know I am doing the right ones ahead of
> time.  :)

In 1.3.1 we added gnutls_certificate_set_x509_simple_pkcs12_file that
is intended to handle encrypted keys and certificates, see the NEWS
entry below.

Admittedly, it uses the same password for all steps, but that seem to
be the common usage.

Maybe that function solves your problem?

I recall trying it on some encrypted key+cert blobs that are used by
OpenSSL-applications; there is a self-test of this in
tests/set_pkcs12_cred.c.

The PKCS#12 format is quite flexible, so I recommend that you keep the
interface minimal in order to have something usable.  A fully flexible
PKCS#12 API would be very complicated, for no practical gain.

Regards,
Simon

** New function to set a X.509 private key and certificate pairs, and/or
CRLs, from an PKCS#12 file, suggested by Emile van Bergen
<emile at e-advies.nl>.

The integrity of the PKCS#12 file is protected through a password
based MAC; public-key based signatures for integrity protection are
not supported.  PKCS#12 bags may be encrypted using password derived
symmetric keys, public-key based encryption is not supported.  The
PKCS#8 keys may be encrypted using passwords.  The API use the same
password for all operations.  We believe that any more flexibility
create too much complexity that would hurt overall security, but may
add more PKCS#12 related APIs if real-world experience indicate
otherwise.