PKCS#11 support for gpg-agent

[Olaf Gellert]

Alon Bar-Lev wrote:

> I won't argue with that...
> But the trend is not in favor of PGP.

And I won't argue about that...

>> OpenPGP offers a completely different trust
>> model which suits the needs of some users
>> very well (you can establish a web of trust
>> with anyone without overhead) while S/MIME
>> (or better: X.509) uses a centralized, CA-
>> based model. For some applications I would
>> never trust a commercial certification
>> authority, so in X.509 you have to operate
>> your own CA...
> 
> You are wrong!
> You can use self-signed certificates in a trust model similar to PGP.

But it's not easy... There is no initial trust
in a self signed certificate but there may be a lot
of trust in a PGP key signed by some special people.
An S/MIME implementation will normally refuse
to import self-signed certificates from emails,
it will only import certificates issued by
an already trusted CA.

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

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 am sorry, but I don't agree.
> I don't find any advantage to keep OpenPGP formats. There is PKCS#7 for
> signed/enveloped data and S/MIME that uses PKCS#7 for email.
> Using self-signed certificates and PKCS#7 and S/MIME you get a full
> replacement for PGP... It will take several years, but eventually it
> will happen.

You do not seem to understand what a web of
trust is. I do have more than 140 signatures
under my PGP key. So whenever someone gets
my key, it is sufficient if he trusts one
of the 140 persons to identify persons.
So how would you do this in X.509? Creating
140 CAs (one for every user)? Then I would
have 140 certificates for the same key?
X.509 uses a centralized model of trust,
only CAs can issue certificates (and a self-
signed cert is only signed by itself, like a
pgp-key without any foreign signatures).
X.509 is different from PGP...

You might read a little bit about cross
certificates and stuff like this, maybe
you figure out some creative ways to build
a web (but I ensure you: This will not work
with many S/MIME implementations: Loops in the
trust paths in X.509 are not supported
too well). See:

http://www.dfn-pca.de/bibliothek/reports/pki-linking/

Unfortunately this report is done by myself,
too...  ;-)

> I hope you read more regarding PKCS#11
> www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html and understand its
> role in cryptographic application and that gpg can benefit from it.

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

Cheers,
   Olaf

-- 
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           og at pre-secure.de

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet