[gnutls-dev] GnuTLS 1.7.8.p11.0
Simon Josefsson
simon at josefsson.org
Fri May 4 14:06:05 CEST 2007
"Alon Bar-Lev" <alon.barlev at gmail.com> writes:
> Hello,
>
> I was about to get this implementation and suggest an alternative,
> only to discover that you are not doing any private key operations.
Hi! Right. I wanted to get things out as soon as possible, and right
now getting the CA trust stuff is all that I can show to be working.
> So there is no implementation to modify, and I don't wish to re-write
> the large part of GnuTLS code.
>
> So I ask you again, please implement a callback structure for engines,
> this callback should have the following methods:
>
> typedef struct {
> void *user_data;
> int (*init)(void *user_data);
> int (*cleanup)(void *user_data);
> int (*sign)(void *user_data, int algorithm, size_t input_size,
> const unsigned char * const input, size_t *output_size, unsigned char
> * const output);
> int (*decrypt)(void *user_data, int algorithm, size_t input_size,
> const unsigned char * const input, size_t *output_size, unsigned char
> * const output);
> } engine_t;
>
> Provide a replacement function for:
> gnutls_certificate_set_x509_key_file ()
> Something like:
> gnutls_certificate_set_x509_key_engine
> (gnutls_certificate_credentials_t res, engine_t *engine)
It will be something like that. It may start out as somewhat simpler,
to better fit with how the GnuTLS API works today: right now
applications can be invoked with a callback to retrieve the appropriate
cert+key. They need some function to get the user certificates and key
handles from the PKCS#11 layer. I'm thinking this interface will be:
int gnutls_pkcs11_get_user_certificates (gnutls_x509_crt_t ** cert_list,
unsigned int *ncerts);
Or similar.
When an application, in the certificate callback, indicate that the
private key is 'NULL', they will have to provider another callback to
perform the sign operation, otherwise the user certificate will be
ignored. That function should likely receive the user certificate or
similar. GnuTLS should have an API available to perform the sign
operation using PKCS#11, but it could also let the application perform
the sign operation in any way it chose. This way, the interface will
not be specific to PKCS#11, but it will be easy to make PKCS#11 work.
> This will allow application to enumerate the token certificates, set
> the trust correctly by using the regular
> gnutls_certificate_set_x509_trust_file() call, and handle the
> sign/decrypt in any way it likes... One implementation may be PKCS#11.
I started providing such an API, but then I realized that it doesn't
work with the callback approach that GnuTLS offers.
gnutls_certificate_set_key etc doesn't do anything if used within a
callback. Hence the current more flexible approach, which doesn't
involve modifying the gnutls_certificate_* functions or structures.
> As I said before, if you provide such interface, I will provide a
> *COMPLETE* and *WORKING* PKCS#11 support for GnuTLS, after a day or
> two.
>
> It will also clean up your implementation, and allow many other
> engines to be added.
>
> Another alternative is to wait for you to have a remotely working
> solution, and create a patch for the above (this is what I intended to
> do now...), but it would be much cleaner if you create the interface
> as you know GnuTLS best, and it will save a lot of work for all.
>
> Please consider to cooperate, you loose nothing, as you will be able
> to use the same interface for your implementation as-well.
Of course! I think the best is for me to produce an API that works for
me and fits with how GnuTLS works. I believe it will be quite close to
what you need, even if not perfectly the same. The API will not be
fixed until it is merged into the normal experimental branch. There
will be several iterations of release on the PKCS#11 branch until that
happens, and your input is valuable here. I think it would be useful to
demonstrate interoperability with at least some other PKCS#11 provider
than Scute until the API is ready.
Regards,
Simon
> Best Regards,
> Alon Bar-Lev.
>
> On 5/2/07, Simon Josefsson <simon at josefsson.org> wrote:
>> Here is the first release on the PKCS#11 branch. The support is
>> currently rather limited, but I decided to make a release early to
>> invite more feedback. The NEWS entry is:
>>
>> * Version 1.7.8.p11.0 (released 2007-05-02)
>>
>> ** New function to get trusted CA certificates from PKCS#11 provider.
>>
>> ** API and ABI modifications:
>> gnutls_pkcs11_get_ca_certificates: ADD.
>>
>> Warning! This is even more experimental than the experimental 1.7.x
>> branch. However, the changes compared to 1.7.8 are intentionally kept
>> minimal, to facilitate easy merging later on.
>>
>> The support is limited to:
>>
>> 1) Support for build-time linking to the PKCS#11 provider scute, see
>> http://www.scute.org/.
>>
>> 2) Retrieving trusted CA certificates from the PKCS#11 provider.
>>
>> To test it, you'll need to build scute from SVN (because it contains a
>> CKA_TRUSTED related fix), and set it up (try using it in mozilla), which
>> can be non-trivial. See the Scute manual. I generated new keys on an
>> OpenPGP smartcard with gpg2 --edit-card and gpgsm-gencert.sh, then
>> signed the CSR with certtool using the GnuTLS test CA, and imported the
>> certificates using 'gpgsm --import'.
>>
>> If someone can explain to me how I can test other PKCS#11 providers, I
>> can test them too. Supporting the NSS soft token provider is an
>> important target.
>>
>> The gnutls-cli tool in this release automatically import all CAs from
>> Scute, and here is an output from running it against the GnuTLS test
>> server:
>>
>> jas at mocca:~$ ~/src/gnutls-pkcs11/src/gnutls-cli --port 5556 test.gnutls.org --ctypes x509
>> Resolving 'test.gnutls.org'...
>> Connecting to '217.13.230.178:5556'...
>> ...
>> - Successfully sent 0 certificate(s) to server.
>> - Certificate type: X.509
>> - Got a certificate list of 1 certificates.
>>
>> - Certificate[0] info:
>> # The hostname in the certificate matches 'test.gnutls.org'.
>> # valid since: Wed Apr 18 15:29:21 CEST 2007
>> # expires at: Thu Apr 17 15:29:21 CEST 2008
>> # fingerprint: 08:8B:4B:0F:68:88:4E:95:15:D6:AC:F6:B3:64:81:5B
>> # Subject's DN: O=GnuTLS test server,CN=test.gnutls.org
>> # Issuer's DN: CN=GnuTLS test CA
>>
>>
>> - Peer's certificate is trusted
>> - Version: TLS 1.2
>> - Key Exchange: DHE RSA
>> - Cipher: AES 256 CBC
>> - MAC: SHA
>> - Compression: DEFLATE
>> - Handshake was completed
>> ...
>>
>> Notice that it says the peer's certificate is trusted, without any
>> --x509certfile. The GnuTLS CA is retrieved from Scute. To debug
>> things, add a '-d 10' and you'll see some debug info:
>>
>> |<2>| PKCS#11 slot count 1
>> |<2>| PKCS#11 slot[1].description: `GnuPG Smart Card Daemon g10 Code GmbH '
>> |<2>| PKCS#11 slot[1].manufacturer: `g10 Code GmbH '
>> |<2>| PKCS#11 slot[1].token.label: `D2760001240101010001000005320000PPC Card Systems OpenPGP 00000532
>> '
>> |<2>| Adding CA certificate 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 (0)
>> |<2>| Skipping certificate BD5F80DE63034EC9E2841E6309552E345C5F226F (0/0)
>>
>> Here the 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 certificate is the
>> GnuTLS CA, and the BD5F80DE63034EC9E2841E6309552E345C5F226F certificate
>> is my client certificate (which is not used as a trusted root).
>>
>> Here are the compressed sources (4.3MB):
>> ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2
>> http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2
>>
>> Here are GPG detached signatures signed using key 0xB565716F:
>> ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2.sig
>> http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2.sig
>>
>> Here are the SHA-1 and SHA-224 checksums:
>>
>> 9fe33805fb5083f5db7be2a3861b2cbd24e818da gnutls-1.7.8.p11.0.tar.bz2
>> 07cf60a582e8a83c10c13e60b6817c6329630f9f gnutls-1.7.8.p11.0.tar.bz2.sig
>>
>> 31abe6790b26eb35964cb14a7b56cd2ad96cdbd29a1c732ad4b7cfae gnutls-1.7.8.p11.0.tar.bz2
>> bd957671b09205c4e6622f438939c311af8401ebf504e0de7f4ad887 gnutls-1.7.8.p11.0.tar.bz2.sig
>>
>> Improving GnuTLS is costly, but you can help! We are looking for
>> organizations that find GnuTLS useful and wish to contribute back.
>> You can contribute by reporting bugs, improve the software, or donate
>> money or equipment.
>>
>> Commercial support contracts for GnuTLS are available, and they help
>> finance continued maintenance. Simon Josefsson Datakonsult, a
>> Stockholm based privately held company, is currently funding GnuTLS
>> maintenance. We are always looking for interesting development
>> projects. See http://josefsson.org/ for more details.
>>
>> /Simon
>>
>> _______________________________________________
>> Gnutls-dev mailing list
>> Gnutls-dev at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>>
>>
>>
More information about the Gnutls-dev
mailing list