On 19/04/14 23:31, Thomas Schittli wrote: > It does not make sense to manage another kind of certs just because > applications that suport/use GnuPG did not added gpgsm support.
> [...] > I made a test with Git: I just renamed gpgsm.exe to gpg.exe. It worked > perfectly! I see the real problem in a different area. gpg.exe with OpenPGP keys generates OpenPGP messages. gpgsm.exe with X.509 certificates generates CMS messages. Applications calling gpg.exe expect an OpenPGP message. If you replace this OpenPGP message by a CMS message, perhaps the application will still work. Or it will break in certain places or break after the author of the application changes it in a way that needs OpenPGP messages, because the author is under the /correct/ impression that gpg.exe gives him an OpenPGP message, or parses an OpenPGP message passed to it. Most applications should be using GPGME anyway instead of calling gpg.exe directly, and X.509 support for GPGME is something that is being worked on, so an application that doesn't mind whether it handles OpenPGP messages or CMS messages can just use the appropriate functions of GPGME. > Therefore I'm pretty sure it was a conceptual error to support X.509 in > another tool. If X.509 were added into gpg, then every application would > immediately had support for both worlds :-) Unfortunately, no. A lot of applications would break. Suppose you are expecting a certain subsystem to generate German messages, and you put those messages on your website. If the subsystem would suddenly switch to Chinese, do you think your clients from Switzerland would be happy that they now had support for both languages, or do you think they would contact support and ask what the #@%& that stuff on your site is supposed to mean? ;) It's up to the applications. If they call gpg.exe directly, they are expecting OpenPGP functionality. You can just break that assumption and hope the application still works, but it seems to me you're breaking the expectations the programmer had when he wrote the code calling gpg.exe directly. On the other hand, if the application uses GPGME, then CMS support (and thus the X.509 trust model) seems to be already in the works, and when applications choose they also want to support that, it might be as easy to support both OpenPGP and CMS as it is to support just one. I don't know if CMS support in GPGME is already usable, but it seems much more viable to do a feature request[1] in that area than to request that the two binaries gpg.exe and gpgsm.exe, which handle completely different messages, be merged into one. I don't think that is going to happen, because it would break a lot of applications. HTH, Peter. [1] Possibly involving funding -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users