[Help-gnutls] RE: Using encrypted keys

[Rich Fought]

That function does sound like it would do the trick, and a lot cleaner.

When does the 1.3.x branch stop being "experimental?"  What does this really
mean?
Should I be wary of moving from 1.2.9 to 1.3.x?

Regards,
Rich

-----Original Message-----
From: Simon Josefsson [mailto:jas at extundo.com] 
Sent: Tuesday, February 21, 2006 6:26 AM
To: Rich Fought
Cc: help-gnutls at gnu.org
Subject: Re: Using encrypted keys

"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.