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

[Werner Koch]

On Wed, 21 Jul 2004 01:10:13 +0200, bsmaillist  said:

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

No, to GnuPG and I am pretty sure the FSF won't agree with that.

> 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 

I know Estland, Finland and Belgium are using pkcs#15 compliant cards
(more or less) and GnuPG supports them trough OpenSC.  So what?  The
forthcoming identity card of the German administration is also based
on pkcs#15 and obviously we support them; I even wrote the required
MICOS driver for OpenSC.

> issued X million PKI cards. Go and buy Outlook if you so desperately want to 
> use that card.". Strange indeed.

And have a lot of fun while random people all over the world are
abusing your digital signature.

> Even OpenSC includes a PKCS#11 implementation because it is extremely relevant 
Yes, they use this to interface OpenSC with Mozilla and other pcks#11
aware applicatiosn - GnuPG makes direct use of OpenSC.

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

No.

> 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 

Reality shows a different picture. Only when both communication
partners use a card from the same vendor, they are fully
interoperable.  Agreed, it is more than pkcs#11 as the entire
infrastructre comes into play.

> playing ground. Why discard that for something which is Free Software but 
> nevertheless proprietary (i.e. the libopensc part of OpenSC).

Huh, there are only a very few APIs defined by standards and many of
them have huge problems.  Standards are good for protocols but not for
all kinds of IPC.

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

Because complexity is the worst enemy of security.  Adding a
superfluous pkcs#11 layer gets you exactly this complexity.  Just for
clarity: The OpenSC pkcs#11 layer is on top of OpenSC and not used to
drive proprietary cards.


Shalom-Salam,

   Werner