Fwd: KMail/GnuPG always report problems with signed S/MIME

[bsmaillist at skynet.be]

On Tuesday 20 July 2004 17:28, Werner Koch wrote:
> On Tue, 20 Jul 2004 16:27:26 +0200, bsmaillist  said:
> > So we have GnuPG excluding all PKCS#11 cards and we have KMail 1.7
> > excluding
>
> Sorry, there are no pkcs#11 cards.  pkcs#11 is merely an API between
> an application and a driver - not with the card.  The host application
> must be aware of the card's application.
>
> The proprietary pkcs#11 drivers try to translate from their
> proprietary card application to something, say, Mozilla can cope with.
> For legal reasons we (GPLed code, e.g. gnupg, KDE) can't link to such
> a driver anyway.

I thought that GPL allows exceptions if you want to link a non-GPL module with 
the GPL'ed software: http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
If my interpretation is correct this would apply to KMail / GnuPG using 
PKCS#11 modules, regardless of these modules' licenses. This exception would 
of course have to be added to the KMail license.

I doubt it very much whether the KMail developers really want to exclude  
potential users who want to use their national eID card for signing e-mails 
(e.g in Estland, Finland, Belgium, Italy, soon in Spain, ...). These people 
don't have much use for the German DINSIG card which will be supported by 
KMail 1.7.

Microsoft is investing heaviily to adapt their flagship application Outlook 
and Office to work with these new national eID card. Should Free Software 
then do the exact opposite and say 'Buzz off, we don't care if your gov't 
issued X million PKI cards. Go and buy Outlook if you so desperately want to 
use that card.". Strange indeed.


> If you have a free driver you will also have the 
> specification of the card - I am not aware of any.

Even OpenSC includes a PKCS#11 implementation because it is extremely relevant 
for the real-world use of a smart card.

>
> Well, pkcs#15 cards basically work (pkcs#15 is a card application
> framework, but you need to tweak it for each card) and we have support
> for them.
>
> Ij general our approach is to access the card directly and use the
> card's applications without any intermediate layer.
>
> > And as far as PKCS#11 being a "silly standard", isn't the operative word
> > here : "standard"?
>
> It is a bunch of defined function calls common to most applications,
> but missing a lot of other required ones. 

That may be true but a poor standard is better than no standard at all.

> Virtually all card 
> application vendors use their own proprietary extensions to pkcs#11.
> Guess why: There is still no market leader and every proprietary
> vendor tries to become the leader. Their tactics are simple: use
> enough of a standard for the marketing dept but make sure the
> application won't interface nicely with another vendors
> product. Sounds common, right?
>

I'm sorry but this does not apply to PKCS#11, not even to these vendors' 
implementation of p11. It is in their own interest to be fully interoperable 
with P11-enabled applications like Mozilla and Lotus Notes. Anything they 
"invent" besides P11 simply won't work with these applications, so is of no 
use to their customers, so does not give the vendor an advantage.

P11, with all its flaws, has at least the advantage of providing a leveled 
playing ground. Why discard that for something which is Free Software but 
nevertheless proprietary (i.e. the libopensc part of OpenSC).

Mind you, using libopensc does have advantages, but why should that exclude 
the use of PKCS#11 as a second alternative?





>
> Shalom-Salam,
>
>    Werner

--