gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] GnuTLS PKCS#11 Engine


From: Simon Josefsson
Subject: Re: [gnutls-dev] GnuTLS PKCS#11 Engine
Date: Mon, 14 May 2007 13:45:47 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux)

"Alon Bar-Lev" <address@hidden> writes:

> On 5/14/07, Simon Josefsson <address@hidden> wrote:
>> I suppose this is just PKCS#11 internal stuff, and I hope you will solve
>> it.  If I can assist in testing anything, let me know.
>
> This is sute problem, I cannot solved this... I CCed Marcus, I hope he
> will be able to solve it.

Yup, right.

>> pkcs11-helper seem to link to OpenSSL by default.  As far as I
>> understand, distributions cannot distribute packages that links
>> pkcs11-helper together with gnutls via your gnutls-pkcs11 legally.
>> Perhaps gnutls and/or gnutls-pkcs11 could check whether pkcs11-helper
>> picks up OpenSSL, and if so, emit an error message.
>
> I don't understand...
> The OpenSSL stuff is not used, I can provide an engine for GnuTLS
> inside the gnutls-pkcs11.
> Even if it linked it is not used.

The license is on the source code, and by using the OpenSSL API I
believe the FSF would consider pkcs11-helper to be a derived work from
OpenSSL, and thus GPL-incompatible.  This would have to be confirmed
with the FSF, though.

>> > Why not just maintain it as sepearate component?
>> > What is the benafit in maintaining one large library?
>>
>> They are separate components, see the pkcs11-branch: there is a
>> standalone libgnutls-pkcs11 library (see the top-level pkcs11/
>> directory) that provides a simple PKCS#11 interface to Scute via the
>> header gnutls/pkcs11.h.  Applications can chose to implement the sign
>> callback using GnuTLS's pkcs11 library, but then they'll have to link to
>> it, or your library, or some other library (that may use CAPI or
>> whatever).
>
> I don't understand...
> The simple scute implementation is irrelevant for 99.999% of users.

That may be true, but as far as I can tell, the simple scute
implementation doesn't harm anything else, so I don't see a problem with
it.

> And if application chooses to use PKCS#11 it can also chose to add a
> library to its linkage.

Yes, that is the point.  Applications that wants to support external
signing will have to do something extra.  That can link to your
gnutls-pkcs11 library, or my scute gnutls-pkcs11 library (there appears
to be a naming conflict here though), or something else, or even
implement everything by itself.  It is even possible to do all at at the
same time, if properly multiplexed by the application.  The nice
property is that the core GnuTLS library doesn't need to know about
this.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]