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

[bsmaillist at skynet.be]

On Wednesday 21 July 2004 09:26, Werner Koch wrote:
> 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.

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 
released? Are there agreements with the growing nr. of governments and other 
card issuers to alert the GnuPG team whenever a new version of a card is 
released? To what extend does the FSF of the GnuPG team give guarantees to 
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 
than all those responsibilities fall onto the card issuer who has to provide 
an up to date PKCS#11 driver with every new version of a card. That (!) is 
why PKCS#11 is relevant.  Whether or not one dislikes the technical aspects 
of the P11 API is not relevant in this context.

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

Good for you and the German civil servants. But most other card issuers won't 
be very thrilled to have to write 1 Windows CryptoAPI CSP for 98% of their 
users and to write a whole set of different drivers for Linux, MacOSX, ... 
for the remaining 2% of their users. For those 2% the card issuer will have 
to provide PKCS#11, GnuPG/OpenSC and CDSA plugins, for 6 flavours of Linux 
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.

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

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

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

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.

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

Yes

> and many of  them have huge problems.

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?

> Standards are good for protocols but not for 
> all kinds of IPC.

Maybe not for all kinds of IPC, but in some cases they are indeed useful.
This should be evaluated on a case by case basis. And in this case I am 
convinced that snubbing PKCS#11 is not beneficial for the KDE/GnuPG user 
community.

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

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 
datastructure on the card uses an open standard like PKCS#15 but the data 
structure was created by the card issuer instead of the card holder (who 
should not be plagued with the technical details). So OpenSC PKCS#11 also 
supports proprietary cards, where proprietary in this context means that the 
card's data structure is defined by the card issuer, not the card holder. 


Come to think of it, without a standard like PKCS#15 the main goal of OpenSC 
to provide a generic smartcard library for crypto cards  would not even be 
possible. Fortunately there are standards that try to make abstraction of
a) how the data is stored on the card (P15)
and
b) how to access and use that data (P11)

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.





>
> Shalom-Salam,
>
>    Werner
>
>
> _______________________________________________
> Gpa-dev mailing list
> Gpa-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gpa-dev