Mailing List Archive

On Tue, 20 Jul 2004 11:46:20 +0200, bsmaillist said:

> newpg 0.9.4

Don't use this package. It is dead and the latest version is pretty
clear about it (i.e. 0.9.5 containss only a README file telling that).

Use gnupg 1.9.9 or better the release we will probably do today.

Werner

On Tuesday 20 July 2004 12:22, Werner Koch wrote:
> On Tue, 20 Jul 2004 11:46:20 +0200, bsmaillist said:
> > newpg 0.9.4
>
> Don't use this package. It is dead and the latest version is pretty
> clear about it (i.e. 0.9.5 containss only a README file telling that).
>
> Use gnupg 1.9.9 or better the release we will probably do today.
>
> Werner

OK. I'm willing to give it a try. Should I deinstall v1.3 first? All the
components?

Does gnupg 1.9.9 support smartcards via PKCS#11?

On Tue, 20 Jul 2004 13:20:04 +0200, bsmaillist said:

> OK. I'm willing to give it a try. Should I deinstall v1.3 first? All the
> components?

No, they peacefully coexist.

> Does gnupg 1.9.9 support smartcards via PKCS#11?

pkcs#11 is a silly standard only useful if you want to hide your
application, driver or whatever. This it is IMHO not useful for FS.

gnupg 1.9 supports a couple of smartcard - if you are able to build
with OpenSC it should support many pkcs#15 card and it natively
support DINSIG, NKS and OpenPGP cards. Access either using ctAPI,
PC/SC or using the native CCID driver.

Werner

On Tuesday 20 July 2004 16:06, Werner Koch wrote:
> On Tue, 20 Jul 2004 13:20:04 +0200, bsmaillist said:
> > OK. I'm willing to give it a try. Should I deinstall v1.3 first? All the
> > components?
>
> No, they peacefully coexist.
>
> > Does gnupg 1.9.9 support smartcards via PKCS#11?
>
> pkcs#11 is a silly standard only useful if you want to hide your
> application, driver or whatever. This it is IMHO not useful for FS.
>
> gnupg 1.9 supports a couple of smartcard - if you are able to build
> with OpenSC it should support many pkcs#15 card and it natively
> support DINSIG, NKS and OpenPGP cards. Access either using ctAPI,
> PC/SC or using the native CCID driver.
>
> Werner

Hi Werner,

Thanks for the reply.

So we have GnuPG excluding all PKCS#11 cards and we have KMail 1.7 excluding
any other crypto plugin but GnuPG. And thus the circle is closed.

I'm sorry but doesn't this exclude more smartcards then it includes?

Doesn't this approach effectively lock out any smartcard for which the issuer
has gone through the trouble of providing Linux versions of his PKCS#11
driver. Why should they still bother with Linux? Even Firebird and
Thunderbord don't support smartcards anymore.

And as far as PKCS#11 being a "silly standard", isn't the operative word
here : "standard"?

Regards

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. If you have a free driver you will also have the
specification of the card - I am not aware of any.

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


Shalom-Salam,

Werner

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

--

On Wednesday 21 July 2004 01:10, bsmaillist@skynet.be wrote:
> 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.

You can pretty much forget about this. KMail's code has been touched by
too many people. Some of them are no longer reachable. Unfortunately
this makes it legally impossible to make changes to the license.

Regards,
Ingo

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

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@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gpa-dev

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

[ S/MIME KMail and GnuPG ]

On Tue, Jul 20, 2004 at 11:46:20AM +0200, bsmaillist@skynet.be wrote:
> None of the signed messages I receive can be verified.
>
> KMail/gpg detects that it is a signed message and displays it accordingly.
> The text body is readable but the signature verification always fails.

One general rule of debugging that stuff is:

Try to seperate the crypto problems from the email problems.
If crypto works, you can check on the problems of the mailer.

In going this route, try to sign a regular file on the command line:
gpgsm -s x >x.sig
gpgsm --verify x

Usually you can see the problems then.
It might be that you do not have CRL in place.

> 1) When I send signed S/MIME messages to myself the messages are displayed as
> "Not enough information to check signature. [Details]
> Status: No status information available."
>
> I would've thought that all the information to verify my own signatures is
> available on my system, especially since GnuPG allows me to sign with that
> particular key/cert. I signed this e-mail using that key and I am curious
> whether it causes problems in other people's KMail/GnuPG setup too.

It might be a bug in newpg 0.9.4 that does not check your own CRL on signing.
I do not remember.

> 2) Some signed mails from third parties cause another error:
> " Not enough information to check signature. [Details]
> Status: Internal system error #0 occurred. "
> e.g. recent mails of Ingo Klöcker on the Aegypten mailing list cause this
> error.

A second step of debugging would be to enable debug logs in all
components and redirect them in a file.

You can also try to save the encoded parts of the emails
and verify the signatures manually on the command line.

> 3) In both cases the [Details] hyperlink does nothing.

It tries to get the certmanager up.
If there is no key you do not get it up.


Apard from that I recommend trying an uptodate gnupg-1.9.
(use CVS or wait for 1.9.10). That is were bugs get fixed.
Bernhard

On Tue, Jul 20, 2004 at 04:27:26PM +0200, bsmaillist@skynet.be wrote:
> On Tuesday 20 July 2004 16:06, Werner Koch wrote:
> > On Tue, 20 Jul 2004 13:20:04 +0200, bsmaillist said:

> > > Does gnupg 1.9.9 support smartcards via PKCS#11?
> >
> > pkcs#11 is a silly standard only useful if you want to hide your
> > application, driver or whatever. This it is IMHO not useful for FS.

Werner, "silly" is not a description that people can understand.
From what I have learned from you, a better description would be:

For Free Software there are technical solutions which are better than pkcs#11
because they are more robust and
basically give you the same funcationality with the same cards.
So instead of going over pkcs#11 which is error prone due to subtle
differences in implementation, we use opensc to access pkcs#15 applications.
The same card applications can be accessed via pkcs#11 in other development
environments. Important for the user is that the card application can
be used stably.

> > gnupg 1.9 supports a couple of smartcard - if you are able to build
> > with OpenSC it should support many pkcs#15 card and it natively
> > support DINSIG, NKS and OpenPGP cards. Access either using ctAPI,
> > PC/SC or using the native CCID driver.

> So we have GnuPG excluding all PKCS#11 cards and we have KMail 1.7 excluding
> any other crypto plugin but GnuPG. And thus the circle is closed.

This puts a negative touch on things, I cannot see warranted.

As explained in this thread: PKCS#11 is an access protocol to cards,
but there are other (better ways) to access the cards.
GnuPG accesses the card application in a different way,
thus no card is excluded by definition.

The modern KMail versions do not use crypto plugins anymore to be precise.
They access gpgme (generation 0.4.x) directly for the integrated
crypto support for PGP/MIME and S/MIME. This integration is non-trivial
and a general api to just put in another cryptobackend is not feasable.
As Kmail is Free Software you can integrate another loadable module, though.
So KMail does not exclude other crypto backend integration by any means.

Regards,
Bernhard

At Wed, 21 Jul 2004 16:18:35 +0200,
Bernhard Reiter wrote:
> The modern KMail versions do not use crypto plugins anymore to be precise.
> They access gpgme (generation 0.4.x) directly for the integrated
> crypto support for PGP/MIME and S/MIME. This integration is non-trivial
> and a general api to just put in another cryptobackend is not feasable.
> As Kmail is Free Software you can integrate another loadable module, though.
> So KMail does not exclude other crypto backend integration by any means.

I am not sure if implementing a new engine for GPGME is more difficult
than writing a new module for KMail. It's probably about the same
type of complexity, although there are differences in the details, and
some aspects of GPGME's interfaces are closely tied to the
--with-colon and --status-fd/--command-fd interfaces of GnuPG/GpgSM.
This might put some people off, because they would be required to glue
in at a string level rather than solely at a C API level. Of course,
one could also try to fix it in GPGME if it is considered too bad.

Oh, and GPGME doesn't support loadable modules at this point.

Thanks,
Marcus

At Thu, 22 Jul 2004 01:56:32 +0200,
Marcus Brinkmann wrote:
> I am not sure if implementing a new engine for GPGME is more difficult
> than writing a new module for KMail.

... unless of course you were really talking about the crypto stuff at
the one level, and the whole message parsing stuff etc at the other
level, in which case there is of course a huge difference.

Thanks,
Marcus