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.
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
