PKCS#11 support for gpg-agent
alon.barlev at gmail.com
Fri Sep 2 22:47:13 CEST 2005
Thank you Olaf,
I see your point regarding PKI, I am familiar with it.
I want to focus the discussion for the smartcard support, this
was my original issue and we then moved to a different
discussion... I have a lot to say in that matter... but first
I will study you documents to understand your position more
I want to come back to the issue of using a standard API to
access the cryptographic token.
>>>Well, you might have a look at KMail, which
>>>uses all the GPG 1.9 stuff. I was impressed
>>>by having a key manager, a smart card daemon
>>>and the easy interface of gpg-agent. This
>>>framework does far more than any PKCS11-
>>>implementation: For exampel it is able to
>>>handle revocation lists and OCSP-queries.
>>>This enables applications to use S/MIME without
>>>re-inventing the wheel.
>>You don't understand what PKCS#11 is!!!!
>>Maybe that is the reason for all of these arguments...
> Well, you might have a look at this report that
> was done by myself and a colleague of mine:
> You might think twice before saying such things
First I am regret if I offended you.
But having written this document how could you state your
previous statement? "This framework does far more than any
I am confused...
If you know that all what PKCS#11 is - access objects on
cryptographic tokens... why did you raise the OCSP and
> But if you integrate Smart-Card functionality
> into the GPG framework, your application does not
> have to care about the smart-card at all. If
> your application uses PKCS11, it still has to
> do CRL-checking, certificate-validation and stuff
> like this. PKCS11 is on quite a low level,
> I would prefer to simply ask the GPG-agent, if
> a used certificate is stil valid (and GPG in turn
> might have a PKCS11 interface to actually
> access the smart card)...
I think otherwise... In current gpg-agent design the smartcard
access should be perform by it.
I think current design is correct one...
But I don't care... As long as a standard PKCS#11 API is used
to access the smartcard... I will be happy.
> For sure, I have read much more about tokens
> and PKCS11 than you think. And even if you
> cannot believe it: It may well be that
> some people have different experiences and
> different opinions and these do not necessarily
> have to be wrong. There are more things than
> black and white...
Again... I am sorry if I offended you.
But I think there are two separate issues here that are
some-how merge together.
Decoding and verifying the PKIX/PGP/PKCS#* data, and accessing
the cryptographic tokens.
These are two separate issues...
One the one hand I have your position that PKCS#11 is not
enough... but you don't provide any replacement... for
standard access to cryptographic token.
On the other hand I have Werner position that states that only
low level APDU access should be defined as low-level card
interface, and every card should be tailored in order to work
This demonstrate the need of adopting a software standard for
gpg for accessing smartcards... and PKCS#11 is the most
I just want us to agree on that.
Whether it is implemented or not is not an issue... I just
wanted to understand why people are developing their own
More information about the Gnupg-users