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

[Werner Koch]

On Wed, 21 Jul 2004 12:00:25 +0200, bsmaillist  said:

> Have you actually tested all these cards? And is the GnuPG organisation 
> planning to redo all these tests every time a new version of those
> cards is 

No and we don't need to. OpenSC does this.  We are making use of the
OpenSC service - whether this is based on the pkcs#11 or the direct
API doesn't matter.  Please read about pkcs#15.

> users of GnuPG or KMail that their (national ID) card will always and at all 
> times be supported? If you would use a generic abstraction layer like PKCS#11 

That is pretty easy: Contract with a company of your choice to
maintain the card - this will give you the guarantee.

> and for 2 flavours of MacOSX. Nice. They will really be motivated when they 
> see the fragmentation of smart card crypto drivers on open sourse platforms.

It is hard to discuss these issues without a sound understanding of
the technical aspects.  For example "driver" is a highly ambigious
term in the field of smartcards.

> Uhm, why would those signature be abused how is the combination 
> KMail/GnuPG/OpenSC any different from Outlook/CryptoAPI/CSP?

Come on, Outlook is a security nightmare. It is insecure by design and
MS is still not able to fix serious flaws after months.


> This is a matter of interoperability of the message format and the certificate 
> format. The card and it's driver don't come into this.

Please define what you mean by driver here.

> Won't argue with that but OpenSC and GnuPG are not without their problems 
> either. Generic and flexible secure PIN entry with a PIN pad card reader of 
> any brand or model for all cards? Anyone?

Ask the crypto industry why they don't agree on a standard or my the
CCID interface is not in wide use.  This comes back to my orginal
point, that they don't want this interoperability.

BTW, a PIN pad won't help against all attacks - it merely gives you a
bit more control on when a signature is made but not about what you
actually sign.  Given that all card vendors are reluctant to publish
the card application's spec there is a good chance that the verify
command is may be bypassed in certain situation.

> convinced that snubbing PKCS#11 is not beneficial for the KDE/GnuPG user 
> community.

Again: We can't link against a non-GPL compatible pkcs#11 library.

If you want a build a pkcs#11 library to make use of gpg-agent's smart
card support, please go ahead.

> OpenSC's PKCS#11 can be used with such proprietary cards as Axalto Cryptoflex, 
> Setec SetCOS and several others. All cards are proprietary, (chip, OS, ...). 
> Sometimes the data structure on the cards is also proprietary. Sometimes the 

I know all this of course.  But it doesn't matter as long as there is
Support in OpenSC for the card.  It took me quite some time to get the
required TCOS/NKS information to write support for it.

> Supporting P11 will offer the same benefits to GnuPG and KMail as P15has 
> offered to OpenSC, i.e. it will make the solution more open, more flexible 
> and suitable for practical use in the real world.

Well, name these benefits.  We do use OpenSC - however there is no
reason to add two stupid pkcs#11 layers.


Shalom-Salam,

   Werner