PKCS#11 support for gpg-agent

[Alon Bar-Lev]

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

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:
> 
> http://www.dfn-pca.de/bibliothek/reports/pki-token/
> 
 > You might think twice before saying such things
 > again...

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 
PKCS11-implementation"???

I am confused...

If you know that all what PKCS#11 is - access objects on 
cryptographic tokens... why did you raise the OCSP and 
revocation stuff?

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

This demonstrate the need of adopting a software standard for 
gpg for accessing smartcards... and PKCS#11 is the most 
suitable standard...
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 
standards.

Best Regards,
Alon Bar-Lev.