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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
