From wk at gnupg.org Thu Aug 4 18:16:14 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Aug 2011 18:16:14 +0200 Subject: [Announce] GnuPG 2.0.18 released Message-ID: <878vr9884x.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.18. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.11) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPLv3+). GnuPG-2 works best on GNU/Linux and *BSD systems but is also available for other Unices, Microsoft Windows and Mac OS X. What's New =========== * Bug fix for newer versions of Libgcrypt. * Support the SSH confirm flag and show SSH fingerprints in ssh related pinentries. * Improved dirmngr/gpgsm interaction for OCSP. * Allow generation of card keys up to 4096 bit. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.18 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.18.tar.bz2 (3922k) gnupg-2.0.18.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.17-2.0.18.diff.bz2 (188k) A patch file to upgrade a 2.0.17 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.18.tar.bz2 you would use this command: gpg --verify gnupg-2.0.18.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.18.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.17.tar.bz2 and check that the output matches the first line from the following list: 5ec2f718760cc3121970a140aeea004b64545c46 gnupg-2.0.18.tar.bz2 998cde3e4383bea771930e9f4934494fa09ed669 gnupg-2.0.17-2.0.18.diff.bz2 Documentation ============= The gnupg.info file has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Almost all mail clients support GnuPG-2. Kmail might be the most prominent user of all GnuPG-2 features. In fact it has been developed in cooperation with the Kmail folks. Mutt users may want to use the configure option "--enable-gpgme" during build time and put a "set use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the reworked OpenPGP support. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: http://www.gnupg.org/service.html Maintaining and improving GnuPG is costly. For more than 10 years now, g10 Code, a German company owned and headed by GnuPG's principal author Werner Koch, is bearing the majority of these costs. To help them carry on this work, they need your support. Please consider to visit the GnuPG donation page at: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 499 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jeanjacquesbrucker at gmail.com Sun Aug 7 10:19:27 2011 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Sun, 7 Aug 2011 10:19:27 +0200 Subject: Add an uid in batch mode Message-ID: <201108071019.32327.jeanjacquesbrucker@gmail.com> Hi is there a way to add an uid in batch mode ? //I have try this :// $ LANGUAGE=en gpg2 --edit-key --batch mykey gpg: can't do this in batch mode // and this // cat << EOF | gpg2 --edit-key mykey > adduid > test_ > test2 at dtc.com > comment > o > save > EOF Why the second way does not work ? it should make things simpler to use gpg in other scripts, no ? (...but maybe with an option to have a standard and international behavior inside gpg prompt, ok.) Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mschoch at gmail.com Sun Aug 7 12:57:43 2011 From: mschoch at gmail.com (Martin Schoch) Date: Sun, 7 Aug 2011 12:57:43 +0200 Subject: Future for GnuPG 1.4.x for Windows Message-ID: <521014543.20110807125743@gmail.com> Hello list I am using GnuPG 1.4.11 on several Windows systems and I have now a question about future development of GnuPG: On the Website of GnuPG.org the link for binaries for Windows goes now to gpg4win Website. But I don't want to download the whole package gpg4win and I don't want to install gnupg 2.x. So there is no other link to download binaries for Windows for GnuPG 1.4.x? -- Best regards, Martin mailto:mschoch at gmail.com From rjh at sixdemonbag.org Sun Aug 7 16:58:58 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 07 Aug 2011 10:58:58 -0400 Subject: Future for GnuPG 1.4.x for Windows In-Reply-To: <521014543.20110807125743@gmail.com> References: <521014543.20110807125743@gmail.com> Message-ID: <4E3EA832.8090102@sixdemonbag.org> On 8/7/2011 6:57 AM, Martin Schoch wrote: > But I don't want to download the whole package gpg4win and I don't > want to install gnupg 2.x. So there is no other link to download > binaries for Windows for GnuPG 1.4.x? ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.11.exe Enjoy! From alex at gpgtools.org Sun Aug 7 18:27:57 2011 From: alex at gpgtools.org (Alexander Willner) Date: Sun, 7 Aug 2011 18:27:57 +0200 Subject: [gpgtools-users] GnuPG 2.0.18 release? In-Reply-To: <-5093511694379896859@unknownmsgid> References: <-5093511694379896859@unknownmsgid> Message-ID: <314D3E1A-C821-4350-8DD4-BECDB0865C14@gpgtools.org> Hi there, On 07.08.2011, at 13:17, Benjamin Donnachie wrote: > On 6 Aug 2011, at 22:38, Martin Paljak wrote: >> Will there be a new release? I'd guess the Lion release will include the new version? > Yes but due to work commitments it is currently a low priority for me. might be a good opportunity to start the next 'call for participation'. We have a foundation for a "simple click'n'run" GnuPG 2 compiling script (see [1]). After some issues are solved this script might be used to easily publish new compiled versions... Best regards, Alex [1] https://github.com/GPGTools/MacGPG2/blob/master/build-script.newWithDownload.sh -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Aug 8 09:25:52 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Aug 2011 09:25:52 +0200 Subject: Add an uid in batch mode In-Reply-To: <201108071019.32327.jeanjacquesbrucker@gmail.com> (Jbar's message of "Sun, 7 Aug 2011 10:19:27 +0200") References: <201108071019.32327.jeanjacquesbrucker@gmail.com> Message-ID: <87fwlcwein.fsf@vigenere.g10code.de> On Sun, 7 Aug 2011 10:19, jeanjacquesbrucker at gmail.com said: > Why the second way does not work ? it should make things simpler to use gpg in other scripts, no ? What you call is a menu and it is subject to change. Thus you may not use any kind of canned commands. The way to add a UID is by using --status-fd and command-fd. GPGME is helpful here but you need to employ a FSM to make it actually working. See the course code of GPA for an example on how to implement it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Aug 8 09:34:46 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Aug 2011 09:34:46 +0200 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: <20110729153116.GG1074@ramsey.cl.cam.ac.uk> (Steven J. Murdoch's message of "Fri, 29 Jul 2011 16:31:16 +0100") References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> <87oc0focdz.fsf@vigenere.g10code.de> <20110727184742.GD1074@ramsey.cl.cam.ac.uk> <87fwlpmrd1.fsf@vigenere.g10code.de> <20110729153116.GG1074@ramsey.cl.cam.ac.uk> Message-ID: <87bow0we3t.fsf@vigenere.g10code.de> On Fri, 29 Jul 2011 17:31, gnupg+Steven.Murdoch at cl.cam.ac.uk said: > I think that plan sounds good, although I still think it is worthwhile for me to > finish off my patch and make it available to those who would like it sooner I understand. My concern is that we need to maintain your API for a long time which I don't like in general but see below. A way in between would be to encode the machine information in the status file you write: CPU, word size and endianess and gpg version should be sufficient for 1.4.x. However this will require a lot of changes with no clear advantage if we eventually put it all into libgcrypt. OTOH, we try to fade out support for 1.4. Thus if we clearly document that this is a 1.4 only option which may change with any new release I won't stand in your way of implementing it as it is right now. > rather than later (I had another private request). Would it still be useful to > do they copyright assignment? If so, please let me know what I should do. Okay, I attach the required templates. In the hope that you may want to contribute other stuff in the future, I send the assign-future template and a text explaining why we need this all. If you send stuff to the FSF please CC me. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: conditions.text URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: request-assign.future URL: From martin at martinpaljak.net Wed Aug 10 18:24:35 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 10 Aug 2011 19:24:35 +0300 Subject: Peaceful coexistence of GnuPG and other smart card software Message-ID: Hello, First of all, I'm really excited about GnuPG 2.0.18 release. Right now CryptoStick v1.2 is the most exciting commonly available smart card/token I have, as it supports 4096 bit RSA keys. This is sweet. It is really exciting also for another reason: it is the only hardware device that actually works with GnuPG, the reason being that using commodity cryptographic hardware through PKCS#11 in GnuPG is virtually impossible (gnupg-pkcs11-scd is not really user-friendly), as recently discussed on this list as well. While I support the cause of the anonymous poster and would welcome the support for PKCS#11 in GnuPG (heck, even OpenSSH folks finally saw the light) I'd like to draw attention to another problem: using an OpenPGP-compatible tokens together with gpg2 and other software that can support the token interface, like OpenSC. I have collected a few issues (and workarounds) about using gpg2 with CryptoStick on Mac OS X (GPGTools) and (Debian)Linux to OpenSC wiki [1]. I've tried looking around in scd/ folder to get an understanding on how things work to provide a patch that would fix some of the problems, namely: - removing exclusive mode and relying on transactions(SCardBeginTransaction/SCardEndTransaction) for smart card access (at least making it *easily* configurable) - support for multiple readers, where the OpenPGP card/token is not the first reader - maybe some better error messages (though I doubt I can/want bite through the scdaemon/assuan/gpg-agent microsystems) Would such changes be of interest and be included with GnuPG? Best, Martin [1] http://www.opensc-project.org/opensc/wiki/OpenPGP#Tips -- @MartinPaljak.net +3725156495 From wk at gnupg.org Thu Aug 11 09:28:46 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Aug 2011 09:28:46 +0200 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: (Martin Paljak's message of "Wed, 10 Aug 2011 19:24:35 +0300") References: Message-ID: <8739h8s8y9.fsf@vigenere.g10code.de> On Wed, 10 Aug 2011 18:24, martin at martinpaljak.net said: > - removing exclusive mode and relying on transactions(SCardBeginTransaction/SCardEndTransaction) for smart card access (at least making it *easily* configurable) That is not possible because scdaemon caches most card informtaion. Thus we need exclusive access or a way to know if other applications changes the card data. A way to workaround this is the scdaemon option: @item --card-timeout @var{n} @opindex card-timeout If @var{n} is not 0 and no client is actively using the card, the card will be powered down after @var{n} seconds. Powering down the card avoids a potential risk of damaging a card when used with certain cheap readers. This also allows non Scdaemon aware applications to access the card. The disadvantage of using a card timeout is that accessing the card takes longer and that the user needs to enter the PIN again after the next power up. Note that with the current version of Scdaemon the card is powered down immediately at the next timer tick for any value of @var{n} other than 0. > - support for multiple readers, where the OpenPGP card/token is not the first reader There is support for multiple readers and it has been tested and used in an actual product many years ago. See --reader-port for a starter. There are likely bugs in it. > - maybe some better error messages (though I doubt I can/want bite through the scdaemon/assuan/gpg-agent microsystems) You mean that it is easier to see things like EEPROM FAILURE? This can be done and is not very complicated. > Would such changes be of interest and be included with GnuPG? I would be more interested in an pcsc driver making use of scdaemon's APDU command. That is using scdaemon as the low-level driver and put pcsc on top of it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Thu Aug 11 11:09:32 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Thu, 11 Aug 2011 12:09:32 +0300 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: <8739h8s8y9.fsf@vigenere.g10code.de> References: <8739h8s8y9.fsf@vigenere.g10code.de> Message-ID: Hello, On Thu, Aug 11, 2011 at 10:28, Werner Koch wrote: > On Wed, 10 Aug 2011 18:24, martin at martinpaljak.net said: > >> ?- removing exclusive mode and relying on transactions(SCardBeginTransaction/SCardEndTransaction) for smart card access (at least making it *easily* configurable) > > That is not possible because scdaemon caches most card informtaion. > Thus we need exclusive access or a way to know if other applications > changes the card data. Well. scdaemon can assume that other applications talk to the same application on the card and do not change *information* but only application state, or start from a "known good state" on every transaction. I have not investigated the normal usage pattern with scdaemon, but I guess it should be feasible. >> ?- support for multiple readers, where the OpenPGP card/token is not the first reader > > There is support for multiple readers and it has been tested and used in > an actual product many years ago. ?See --reader-port for a starter. > There are likely bugs in it. Readers often change dynamically, especially with laptops. The logical solution would be location a suitable card from all present readers, not changing scdaemon.conf on every invocation. To be honest, I'm using OpenPGP through gpg2, where the only options are --card-edit and --card-status. I don't know if I would want to know the presence and internals of gpg2/gpg-agent/scdaemon if I don't *have* to. >> ?- maybe some better error messages (though I doubt I can/want bite through the scdaemon/assuan/gpg-agent microsystems) > > You mean that it is easier to see things like EEPROM FAILURE? ?This can > be done and is not very complicated. I mean meaningful errors that would help me to locate the problem, like "no readers present" or "agent is faulty" instead of "Card error" or "Unsupported certificate". >> Would such changes be of interest and be included with GnuPG? > > I would be more interested in an pcsc driver making use of scdaemon's > APDU command. ?That is using scdaemon as the low-level driver and put > pcsc on top of it. That's more like a chicken and egg problem. Rest of the world uses PC/SC and manages to get things done. It is far from a perfect solution (the same for PKCS#11) but it works and is something people from several sectors have managed to work with and build upon. If there was a greedy application stack to allocate a device, it should be the most appropriate and standard piece of the system. IMHO PC/SC is that. Best, Martin From wk at gnupg.org Thu Aug 11 14:51:45 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Aug 2011 14:51:45 +0200 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: (Martin Paljak's message of "Thu, 11 Aug 2011 12:09:32 +0300") References: <8739h8s8y9.fsf@vigenere.g10code.de> Message-ID: <87ty9oqffi.fsf@vigenere.g10code.de> On Thu, 11 Aug 2011 11:09, martin at martinpaljak.net said: > Well. scdaemon can assume that other applications talk to the same > application on the card and do not change *information* but only Assuming something is not a good operation mode for a security application. An easy way out of the exclusive access scheme would be a notification from pcscd when an application has changed the card's state so that scdaemon may flush its cache. > Readers often change dynamically, especially with laptops. The logical > solution would be location a suitable card from all present readers, > not changing scdaemon.conf on every invocation. To be honest, I'm Scdaemon uses a reader id made up from the USB vendorid, productid and the serialnumber. For PC/SC access the PC/SC reader name is used. Configuration utilities may use: $ gpg-connect-agent 'scd getinfo reader_list' /bye D 04E6:5116:21120804208192:0%0A OK (this command does not yet list PC/SC reader). > I mean meaningful errors that would help me to locate the problem, > like "no readers present" or "agent is faulty" instead of "Card error" > or "Unsupported certificate". One problem hese is that we try to use the same code for GnuPG-1 and GnuPG-2. We could get better error messages for the GnuPG-2 only case. > That's more like a chicken and egg problem. Rest of the world uses > PC/SC and manages to get things done. It is far from a perfect I have no problems with PC/SC; I merely suggest to loop PC/SC access through scdaemon ;-) > If there was a greedy application stack to allocate a device, it > should be the most appropriate and standard piece of the system. IMHO > PC/SC is that. This is low-level and can't do the things a high-level application like scdaemon is able to do. Did you ever try to use X.509 card with several applications - it takes ages do anything because card I/O is slow and X.509 requires you to read a lot of stuff. Well, unless the application "assumes" a certain state of the card. Ask some tester of the German Health Card prototypes about their experience with the speed of the applications (and that is mostly card I/O and not network bounded). Scdaemon might not be the best design around as it is now a decade old but it has advantages over other solutions. The Free Software community should at least demand free card specs to allow the implementation of the card's host part using Free Software. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Thu Aug 11 15:53:43 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Thu, 11 Aug 2011 16:53:43 +0300 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: <87ty9oqffi.fsf@vigenere.g10code.de> References: <8739h8s8y9.fsf@vigenere.g10code.de> <87ty9oqffi.fsf@vigenere.g10code.de> Message-ID: On Thu, Aug 11, 2011 at 15:51, Werner Koch wrote: > On Thu, 11 Aug 2011 11:09, martin at martinpaljak.net said: >> Well. scdaemon can assume that other applications talk to the same >> application on the card and do not change *information* but only > > Assuming something is not a good operation mode for a security > application. Even though "assumption is the mother of all screw ups", the card is mostly used to access cryptographic keys. Verifying the cryptographic integrity if the response from the card is far better and meaningful than tracking "card state". > > An easy way out of the exclusive access scheme would be a notification > from pcscd when an application has changed the card's state so that > scdaemon may flush its cache. Define "changed the card's state" ? There's SCARD_W_RESET_CARD. I know that this is probably not what you mean, but still. Also, I don't know how GnuPG works on Windows, but I doubt it is easy or even possible to change the way Windows PC/SC service works. >> Readers often change dynamically, especially with laptops. The logical >> solution would be location a suitable card from all present readers, >> not changing scdaemon.conf on every invocation. To be honest, I'm > > Scdaemon uses a reader id made up from the USB vendorid, productid and the > serialnumber. ?For PC/SC access the PC/SC reader name is used. > Configuration utilities may use: > > ?$ gpg-connect-agent 'scd getinfo reader_list' /bye > ?D 04E6:5116:21120804208192:0%0A > ?OK > > (this command does not yet list PC/SC reader). OK, that's why I got nothing. I'm using it through PC/SC of course, for the previously outlined reasons. Numbering of the readers changes if you re-plug readers to different connectors (or in different order). OpenSC also used to have "static numbering of connected readers" but this has proven to be inefficient in current environments as (well, mostly for PKCS#11 based applications, more established platforms (Windows, OS X) have their own frameworks) >> That's more like a chicken and egg problem. Rest of the world uses >> PC/SC and manages to get things done. It is far from a perfect > > I have no problems with PC/SC; I merely suggest to loop PC/SC access > through scdaemon ;-) You mean using scdaemon+its CCID driver instead of libccid? Why? Any practical reasons? I don't think it is very practical. I believe Ludovic's CCID driver is currently the most complete and tested driver (as it is used by *many* and various applications, readers, cards and users). >> If there was a greedy application stack to allocate a device, it >> should be the most appropriate and standard piece of the system. IMHO >> PC/SC is that. > > This is low-level and can't do the things a high-level application like > scdaemon is able to do. ?Did you ever try to use X.509 card with several > applications - it takes ages do anything because card I/O is slow and > X.509 requires you to read a lot of stuff. ?Well, unless the application > "assumes" a certain state of the card. ?Ask some tester of the German > Health Card prototypes about their experience with the speed of the > applications (and that is mostly card I/O and not network bounded). Accessing smart cards is a low level thing. Much like accessing USB devices. Or PCI cards. Or other external hardware. Yes, one of the things missing in Linux is a "central service" (a daemon) that manages the "more meaningful" higher level access to smart cards (Tokend on OS X/Minidriver in Windows) and it stems from the lack of an agreed-upon framework in Linux. There would be GSecurity vs QSecurity (or KSecurity). Like there would be a hierarchical-security vs weboftrust-security standoff. But a slow yet working multi-application experience beats a fast-but-not-working experience any time. There are tricks like caching the "heavy X509" things (certificates) and resetting+transaction the card for every granular operation that help to remedy the problem. I think it would make sense that everybody agrees upon having a single interface to talk to actual smart card devices. And build upon it. The same way it would make sense to support PKCS#11 and let the user decide what he/she wants to risk with - either using his keys with a proprietary (or free!) PKCS#11 stack with GnuPG or being forced to the ugly bad world of X509, PKCS#11 and greedy CA-s ;) > Scdaemon might not be the best design around as it is now a decade old > but it has advantages over other solutions. ?The Free Software community > should at least demand free card specs to allow the implementation of > the card's host part using Free Software. While I feel your concern for open specs (OpenSC has many open source drivers with no public docs at the same time), but there's a practicality vs purity balance somewhere. Yet another place to re-implement the same thing (how to access a card with cryptographic keys) does not help either. I'll write a separate e-mail about my current problems of using CryptoStick with GnuPG (GPGTools) on OS X together with OpenSC. This can't be changed with some support (code changes) from GnuPG. Cheers, Martin From nicholas.cole at gmail.com Fri Aug 12 12:05:28 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 12 Aug 2011 11:05:28 +0100 Subject: Trust Signature and Trust Level Bug Message-ID: Dear List, I think I have found two bugs in the way that gpg handles the interaction between trust signatures and locally assigned owner trust. I'm using version 1.4.11. I have not verified on version 2. To verify: Create Three Keys Root Key (set as ultimate trust) Middle Key (Sign the User ID with a Trust Signature - full trust) [ middle key would then sign other keys, but this is not needed to explain these bugs] The bugs all concern the user attempting to set an explicit Trust to "Middle Key" Bug 1 (minor): ========== Just after "Middle Key" has been signed, gpg may allow the user to change the trust setting of the key to an arbitrary value. I *think* at some point after this the trust database gets updated, and attempting to set trust displays the message: The minimum trust level for this key is: full The sure way to prompt this is in fact to set the trust level of the key to a lower level than the trust signature. gpg seems to accept the first attempt, but subsequent attempts will fail. Bug 2 (more serious): ================ GPG will not allow the user to set the trust of the key independently of the trust signature, even when Trust Signature is domain-limited. So - Supposing that "Root Key" signs "Middle Key" with a trust signature limited to the ".gnupg.invalid" domain. The user might independently decide to assign "Middle Key" a marginal trust setting for all keys. The *expected outcome* here is that within the domain .gnupg.invalid the key is allowed to sign with "Full Trust" but that in all other domains it just has marginal trust. However, the *actual outcome* is that gpg will not let the user assign anything less than "Full Trust" to this key. Having set Full Trust the user is not able to change his mind and set the trust level to anything less than Full Trust, without first setting the trust level of "Root Key" to something lower. Suggestion ======== That GPG should stop trying to second-guess the user and allow the user to set any trust level on a key. Instead, it could display a warning that this may be overridden by trust signatures on a key when calculating the validity of keys within the domain of the trust signature. Best wishes, Nicholas From dkg at fifthhorseman.net Sat Aug 13 04:03:38 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2011 22:03:38 -0400 Subject: Trust Signature and Trust Level Bug In-Reply-To: References: Message-ID: <4E45DB7A.8030503@fifthhorseman.net> Hi Nicholas-- I'm not on the gnupg team myself, but i've looked at this kind of situation too. thanks for your writeup! notes below... On 08/12/2011 06:05 AM, Nicholas Cole wrote: > Bug 1 (minor): > ========== > > Just after "Middle Key" has been signed, gpg may allow the user to > change the trust setting of the key to an arbitrary value. > > I *think* at some point after this the trust database gets updated, > and attempting to set trust displays the message: > > The minimum trust level for this key is: full > > The sure way to prompt this is in fact to set the trust level of the > key to a lower level than the trust signature. gpg seems to accept > the first attempt, but subsequent attempts will fail. This inconsistency does seem like a bug; i agree with you that it seems minor. A bigger problem seems to me that there ought to be a way for the user to explicitly override a trust signature's delegation. For example, if the root key says "trust the middle key", and you as a user happen to know that the middle key has been compromised, you shouldn't have to wait for the root key to get around to revoking their trust signature. > Bug 2 (more serious): > ================ > > GPG will not allow the user to set the trust of the key independently > of the trust signature, even when Trust Signature is domain-limited. I think this definitely a concern. Could you open a ticket at https://bugs.g10code.com/ to record your observation and any proposed changes in behavior? Note that very few people actually use trust signatures to my knowledge; so these edge cases you're exploring are not likely to bite a large number of users. However, i think these edge cases are some of the reasons that trust signatures are confusing and difficult to work with, which is one of the reasons no one has bothered to try to use them in any significant public way yet. So talking through the potential problems could be quite useful. > That GPG should stop trying to second-guess the user and allow the > user to set any trust level on a key. Instead, it could display a > warning that this may be overridden by trust signatures on a key when > calculating the validity of keys within the domain of the trust > signature. I think a "this may be overridden" warning is much less useful than an explicit warning that "your setting has been overridden"; but, more importantly, i don't think that gpg should be overriding user preferences that have been explicitly and directly stated. I'm curious to hear what Werner and David think about these issues. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Sat Aug 13 12:07:54 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 13 Aug 2011 11:07:54 +0100 Subject: Trust Signature and Trust Level Bug In-Reply-To: <4E45DB7A.8030503@fifthhorseman.net> References: <4E45DB7A.8030503@fifthhorseman.net> Message-ID: On Sat, Aug 13, 2011 at 3:03 AM, Daniel Kahn Gillmor [snip] >?Could you open a ticket at > https://bugs.g10code.com/ to record your observation and any proposed > changes in behavior? Dear David, I've opened a bug - https://bugs.g10code.com/gnupg/issue1361 I've slightly expanded the write-up there, and included a more extended discussion. Where a user specifies two logically inconsistent things, the question is which one to honour. Given the typical use-cases for trust signatures, I think it makes sense to honour the trust signature, which is in line with gpg's current operation. However, it is clearly a security issue if a trust signature can trick/force a user to end up trusting a key for cases not intended by the trust signature. I'm sure this a case of the User Interface trying to be too clever, rather than a more serious underlying issue. Best wishes, Nicholas From yurchor at ukr.net Sun Aug 14 11:52:20 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Sun, 14 Aug 2011 12:52:20 +0300 Subject: Translation of GnuPG Tools descriptions Message-ID: Hi! Tools descriptions in /tools/gpgconf-comp.c are addressed to NULL PO domain name, not extracted and so untranslatable: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=tools/gpgconf-comp.c;h=bcdecfd89e5dbd798a0ee0193abbc73a2b3e6dec;hb=refs/heads/master 1024: gc_component[] = { { "gpg", NULL, "GPG for OpenPGP", gc_options_gpg }, { "gpg-agent", NULL, "GPG Agent", gc_options_gpg_agent }, { "scdaemon", NULL, "Smartcard Daemon", gc_options_scdaemon }, { "gpgsm", NULL, "GPG for S/MIME", gc_options_gpgsm }, { "dirmngr", NULL, "Directory Manager", gc_options_dirmngr }, { "pinentry", NULL, "PIN and Passphrase Entry", gc_options_pinentry } }; Is this done on purpose? Some frontends (e.g. Kleopatra) use these descriptions in GUI [1]. Thanks in advance for your answers. Best regards, Yuri [1] http://ompldr.org/vOXc1eA/kleo.png From martin at martinpaljak.net Mon Aug 15 15:00:18 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Mon, 15 Aug 2011 16:00:18 +0300 Subject: [rant] using a hardware token with GnuPG Message-ID: <4E491862.6060906@martinpaljak.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have a CryptoStick v1.2 and up to date Debian sid (amd64). I'm having some hard time trying to set Enigmail to work, in fact, getting GnuPG to work with a smart card at all. Make no mistakes, this is a rant. But from a user who is not an absolute beginner (meaning it is porobably even more confusing for newcomer average Ubuntu users) nor with eye patches, meaning I'm trying to be realistic and practical when it comes to matters of software, security or smart cards in that matter. This is what I have installed: GnuPG 2: $ gpg2 --version gpg (GnuPG) 2.0.17 libgcrypt 1.4.6 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 GnuPG 1: $ gpg --version gpg (GnuPG) 1.4.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 My setup looks as foolows: a keybaord with a smart card reader and a smart card reader + fingerprint scanner which are always connected. And one CryptoStick, which most of the time is supposed to sit in my pocket. Every now and then I have other smart card readers (could be as many as tens of readers) connected as well, for example a proper pinpad reader for when I use my eID for legally binding signatures. If I could change my keybaord against a plain keyboard then keep in mind that many modern laptop computers come with a built-in smart card reder. Which is always present. So the list is often dynamic in real life. $ opensc-tool -l # Detected readers (pcsc) Nr. Card Features Name 0 No HP USB Smart Card Keyboard [CCID Interface] (0817563f) 00 00 1 No ACS ACR 38U-CCID 01 00 2 Yes German Privacy Foundation Crypto Stick v1.2 02 00 I already had the CryptoStick set up with a self-compiled GnuPG 2.0.18 to make use of 4096 keys (how is outside of the scope of this e-mail), I re-installed from Debian packages after initializing the token. This is how the token looks like: $ gpg2 --card-status scdaemon[7191]: PC/SC RESET failed: no smartcard (0x8010000c) scdaemon[7191]: apdu_send_simple(0) failed: no card scdaemon[7191]: can't select application `openpgp': Card not present gpg: selecting openpgp failed: Card not present gpg: OpenPGP card not available: Card not present scdaemon[7191]: updating slot 0 status: 0x0000->0x0004 (0->1) $ scdaemon[7191]: scdaemon (GnuPG) 2.0.17 stopped Interesting, I have the token inserted alright, how come the card is not present? (read and learn about scdaemon and --reader-port option). So I know that I should adjust a configuration file every time the configuration of my pluggable USB devices changes. Fine, luckily I have opensc-tool installed to check my connected readers at the moment. $ echo 'reader-port "German Privacy Foundation Crypto Stick v1.2 02 00"' > ~/.gnupg/scdaemon.conf $ cat ~/.gnupg/scdaemon.conf reader-port "German Privacy Foundation Crypto Stick v1.2 02 00" A new try: $ gpg2 --card-status scdaemon[6870]: PC/SC OPEN failed: sharing violation gpg: selecting openpgp failed: Card error gpg: OpenPGP card not available: Card error $ scdaemon[6870]: scdaemon (GnuPG) 2.0.17 stopped Something changed, a different error! Whoops, I have a browser (Chrome) running (like many people do), which could theoretically make use of the X509 certificate on the token through a PKCS#11 driver. I have not yet found a piece of software that would allow to write the actual certificate to the card. But OpenSC PKCS#11 can make use of the keys on the tokend, for example for SSH authentication with OpenSSH (which would mean killing all open SSH sessions making use of the token as well). OpenSC tries to be friendly and actually is not blocking other software from accessing the card when it is not actually doing crypto with the card: $ opensc-tool -lv # Detected readers (pcsc) Nr. Card Features Name 0 No HP USB Smart Card Keyboard [CCID Interface] (0817563f) 00 00 1 No ACS ACR 38U-CCID 01 00 2 Yes German Privacy Foundation Crypto Stick v1.2 02 00 3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c CryptoStick v1.2 (OpenPGP v2.0) [IN USE] Nevertheless, I'll go on and kill all my browser windows for the duratin of writing rest of the e-mail. Again a new try: $ gpg2 --card-status Application ID ...: D2760001240102000005000005460000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00000546 Name of cardholder: Martin Paljak Language prefs ...: et Sex ..............: male URL of public key : http://martinpaljak.net/pgp.asc Login data .......: martin Signature PIN ....: forced Key attributes ...: 4096R 4096R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 39 Signature key ....: B444 E75C 6A7D 4C77 20ED D06C 7482 655E 307E 3452 created ....: 2011-08-10 13:12:43 Encryption key....: 475A 3D34 681B 7498 81BC E02E 9140 D7C7 0121 2BA2 created ....: 2011-08-10 13:12:43 Authentication key: 12D5 7AA0 F048 7484 8BA6 D902 1798 DE28 20D9 1C31 created ....: 2011-08-10 13:12:43 General key info..: pub 4096R/307E3452 2011-08-10 Martin Paljak sec> 4096R/307E3452 created: 2011-08-10 expires: never card-no: 0005 00000546 ssb> 4096R/20D91C31 created: 2011-08-10 expires: 2016-08-08 card-no: 0005 00000546 ssb> 4096R/01212BA2 created: 2011-08-10 expires: 2014-08-11 card-no: 0005 00000546 Okay. Much better. I seem to have a recognized smart card with nice and shiny 4096 bit RSA keys in hardware. Security++. So I'd like to use the device to send encrypted and signed e-mails to peple using GnuPG. I downloaded Thunderbird 5 + Enigmail 1.2.1 (the one from the website, not through addons browser inside Thunderbird, which still offers only 1.2 which is apparently buggy) for that purpose. I configure Enigmail to use /usr/bin/gpg2 as I think I should want to use the newer and better GnuPG 2. I was for a while also under the impression that I *need* to use GnuPG 2 because I have these huge keys. Sending signed messages fails though: Send operation aborted. Error - encryption command failed gpg command line and output: /usr/bin/gpg2 gpg: signing failed: No pinentry gpg: [stdin]: clearsign failed: No pinentry For a while lets forget Enigmail. I was able to set it up so that I could actually send signed messages, but I forgot how it happened, was I using gpg2 or gpg1 or with what exact settings. But it worked with some tweaking and wrapping binaries with proper environment. I'll fall back to checking my setup on the terminal. So I think I have my keys nicely present and usable for GnuPG: $ gpg2 --list-keys martin at martinpaljak.net pub 4096R/307E3452 2011-08-10 uid Martin Paljak uid Martin Paljak uid Martin Paljak uid [jpeg image of size 8681] sub 4096R/20D91C31 2011-08-10 [expires: 2016-08-08] sub 4096R/01212BA2 2011-08-10 [expires: 2014-08-11] $ gpg2 --list-secret-keys martin at martinpaljak.net sec> 4096R/307E3452 2011-08-10 Card serial no. = 0005 00000546 uid Martin Paljak uid Martin Paljak uid Martin Paljak uid [jpeg image of size 8681] ssb> 4096R/20D91C31 2011-08-10 [expires: 2016-08-08] ssb> 4096R/01212BA2 2011-08-10 [expires: 2014-08-11] Lets go and sign some data: $ gpg2 --clearsign Hello, World! Hello, World! scdaemon[8431]: signatures created so far: 41 scdaemon[8431]: DBG: asking for PIN '||Please enter the PIN%0A[sigs done: 41]' (pinentry:8442): GLib-GObject-CRITICAL **: Object class GtkSecureEntry doesn't implement property 'editing-canceled' from interface 'GtkCellEditable' scdaemon[8431]: updating slot 0 status: 0x0000->0x0007 (0->1) $ scdaemon[8431]: scdaemon (GnuPG) 2.0.17 stopped If you omit the Gtk garbage, I get a nice PIN entry window, enter my PIN and voila, get a signature. Lets try encryption: $ echo "test" | gpg2 -ear martin at martinpaljak.net | gpg2 -d gpg: encrypted with 4096-bit RSA key, ID 01212BA2, created 2011-08-10 "Martin Paljak " gpg: public key decryption failed: General error gpg: decryption failed: No secret key scdaemon[8465]: updating slot 0 status: 0x0000->0x0007 (0->1) $ scdaemon[8465]: scdaemon (GnuPG) 2.0.17 stopped Decryption failed - why? I have the mentioned key nicely visible through gpg2 ? Maybe gpg-agent is necessary for this to work. Lets try: $ eval `gpg-agent --sh --daemon` $ echo $GPG_AGENT_INFO /tmp/gpg-7kOvKr/S.gpg-agent:8850:1 $ echo "test" | gpg2 -ear martin at martinpaljak.net | gpg2 -d gpg: encrypted with 4096-bit RSA key, ID 01212BA2, created 2011-08-10 "Martin Paljak " gpg: public key decryption failed: General error gpg: decryption failed: No secret key No. Still no luck. (go to IRC, learn that trying gpg1 might give a different result. Consecutively learn that maybe I might not need gpg2 at all) So lets try with gpg1. First, verify that keys are visible: $ gpg --list-keys martin at martinpaljak.net pub 4096R/307E3452 2011-08-10 uid Martin Paljak uid Martin Paljak uid Martin Paljak uid [jpeg image of size 8681] sub 4096R/20D91C31 2011-08-10 [expires: 2016-08-08] sub 4096R/01212BA2 2011-08-10 [expires: 2014-08-11] $ gpg --list-secret-keys martin at martinpaljak.net sec> 4096R/307E3452 2011-08-10 Card serial no. = 0005 00000546 uid Martin Paljak uid Martin Paljak uid Martin Paljak uid [jpeg image of size 8681] ssb> 4096R/20D91C31 2011-08-10 [expires: 2016-08-08] ssb> 4096R/01212BA2 2011-08-10 [expires: 2014-08-11] Yes, available. Lets try decrypting with gpg1 (but continue the failsafe encryption operation with gpg2 just for fun) $ echo "test" | gpg2 -ear martin at martinpaljak.net | gpg -d gpg: detected reader `HP USB Smart Card Keyboard [CCID Interface] (0817563f) 00 00' gpg: detected reader `ACS ACR 38U-CCID 01 00' gpg: detected reader `German Privacy Foundation Crypto Stick v1.2 02 00' gpg: apdu_send_simple(0) failed: no card Please insert the card and hit return or enter 'c' to cancel: Again, no card. (learn that gpg1 and gpg2 work entirely differently when it comes to accessing smart cards and the --reader-port option to gpg1) Lets try again: $ echo "test" | gpg2 -ear martin at martinpaljak.net | gpg -d --reader-port "German Privacy Foundation Crypto Stick v1.2 02 00" gpg: detected reader `HP USB Smart Card Keyboard [CCID Interface] (0817563f) 00 00' gpg: detected reader `ACS ACR 38U-CCID 01 00' gpg: detected reader `German Privacy Foundation Crypto Stick v1.2 02 00' gpg: pcsc_connect failed: sharing violation (0x8010000b) gpg: apdu_send_simple(0) failed: locking failed Please insert the card and hit return or enter 'c' to cancel: A "sharing violation" error. It turns out that the gpg-agent started before grabs exclusive access for the reader and is the source of conflict with gpg1 (even though I have "card-timeout 1" in ~/.gnupg/scdaemon.conf): $ pstree | grep scdaemon |-gpg-agent---scdaemon $ opensc-tool -lv # Detected readers (pcsc) Nr. Card Features Name 0 No HP USB Smart Card Keyboard [CCID Interface] (0817563f) 00 00 1 No ACS ACR 38U-CCID 01 00 2 Yes German Privacy Foundation Crypto Stick v1.2 02 00 3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c [EXCLUSIVE] OK, clean up: $ killall gpg-agent $ unset GPG_AGENT_INFO And try again: $ echo "test" | gpg2 -ear martin at martinpaljak.net | gpg -d --reader-port "German Privacy Foundation Crypto Stick v1.2 02 00" gpg: detected reader `HP USB Smart Card Keyboard [CCID Interface] (0817563f) 00 00' gpg: detected reader `ACS ACR 38U-CCID 01 00' gpg: detected reader `German Privacy Foundation Crypto Stick v1.2 02 00' Please enter the PIN gpg: encrypted with 4096-bit RSA key, ID 01212BA2, created 2011-08-10 "Martin Paljak " test FINALLY! I successfully decrypted with GnuPG, with the key on my smart card! I only lost the nice graphical PIN entry box, instead the PIN code was asked on the terminal. So lets take this knowledge to Enigmail and don't override the default used gpg with gpg2, maybe this way I can use Enigmail as well. The first try with a clean stup failed, giving the current reader name in expert options under advanced section finally worked (as you can see, the e-mail *is* signed, with the right key). I made a small wrapper that locates the CryptoStick form connected readers to make my life easier, but I guess this is not a thing for everyone. So a few questions: * Is the differences between GnuPG 1 and GnuPG 2 described somewhere, in the scope of smart card access? * What should I use then, gpg1 or gpg2? At least generation of keys required GnuPG 2.0.18 to get the 4096 bit keys. * Am I lazy, stupid or just unlucky, that the process of getting this to work was a quite tough experience? * How to debug the problem with gpg2? How exactly does the interaction to smart cards happens with GnuPG2? Is the agent *necessary* (I have no passwords or PIN codes that should be cached, just the hardware token) * If I was to go and try fix the code to get rid of some of the annoying bugs regarding handling smart card readers and smart cards, how should I proceed (like locating the "most appropriate" card reader automatically)? Should I work with gpg2 or gpg1? * Does the OpenPGP card (the one sold by g10code.com) also support 4096 bit keys or is the CryptoStick the only device? I really hope the situation could be cured, so that the solution would be without eye patches and as standard as possible. Meaning reasonable sharing of hardware resources though PC/SC between different applications. Once the actual X509 certificate support for OpenPGP v2.0 cards would be in OpenSC, I would not want to even speculate what kind of interoperability problems would arise from trying to use a browser and Enigmail at the same time... Cheers, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOSRhcAAoJEHSCZV4wfjRShp0P/0OME4Sm7UEQ1tKf4IdwaDJx ytIG93QLe+p9XX41RdDe8npc356zC3xCTFt+0MciuIrSjDzwKp0ZScCVbpj/XwWP SNaVGFTmSGLc7xr5y5xtF+X6LwL4HHAfnj7tkmIBM52MJvl2BN0dz53XQR628gIJ d4zAaO++/Bh/I5lA5qNcqKaWX1Osw9HMrgRanOx6b7G/jElmxStO+7hzAkiDDBrA 7h1ndePa8F97Pe4k9oimF1gYdNSV3SLqkjuR3W1drnceq1MDk1+DIe3/TmbLABW8 bq3WyeFnsnyUQsVlA8dqsWTzD1A2VTnp39HZd7vKepG04diGGi197rGls8TkXjFq UmgEne5YJehJLD8VEzhHXcN6Z+ZTwLUKonHC74erzTarF0ChtDRQnmHYqkoZ31Te rttKmMVNRuPGSbsDWz5SvBTYorNdFG26Gc1zYEnjbb++AO5vzcs00MwQs1luXKxq LK+rGSfPbrT5f6XJ9siTZtQi97vfs/EthohRez9ksB3qyhrqLjAQVVOEMAz05ZPJ QpvzpiUCP9dMg0HdM7r4YkfFi5anGkQd3HjZ9qTGcggTem5wftnYEESKNi5a1GKA Vg43IHnEYFjM831ZufNAF5Kqam2kgWrIrCQNWdWF4pR4jV2h9WLnIi7tIEIi/vyh 9zoWFG5NAoQPaTXH/E2P =iBej -----END PGP SIGNATURE----- From ml at schoenitzer.de Mon Aug 15 18:46:16 2011 From: ml at schoenitzer.de (Michael Florian =?iso-8859-1?q?Sch=F6nitzer?=) Date: Mon, 15 Aug 2011 16:46:16 +0000 (UTC) Subject: Program announce: gpgkeymgr Message-ID: Hi, I'd like to announce the first official version (0.2) of the new program gpgkeymgr. It is an small tool for managing and cleaning up you're keyring, by removing old and unnecessary keys. Currently if supports the following features: - remove expired keys - remove revoked keys - remove not-valid keys, optional with given level - remove not-trusted keys, optional with given level - remove key listed in a file - backup you keyring - AND or OR mode for key choosing - secret key will not be touched - multilingual (english & german for now) You can find it here: http://nudin.github.com/GnuPGP-Tools/ I'm not an experienced developer, so I'm not sure about my code fitting Code-quality standards and would be glad about any feedback. Furthermore I'd also like to get feedback about features wishes, bug reports, etc. Happy hacking, Michi -- Michael F. Sch?nitzer Mail: michael ?t schoenitzer.de Homepage: http://www.schoenitzer.de Jabber: Schoenitzer at jabber.piratenpartei.de From marcus.brinkmann at ruhr-uni-bochum.de Tue Aug 16 12:15:16 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 16 Aug 2011 12:15:16 +0200 Subject: [rant] using a hardware token with GnuPG In-Reply-To: <4E491862.6060906@martinpaljak.net> References: <4E491862.6060906@martinpaljak.net> Message-ID: <4E4A4334.5090702@ruhr-uni-bochum.de> Hi, gpg-agent is an integral part of any gnupg 2 environment. It should be started as part of your session and be visible to all programs within it. BTW, the OpenPGP cards are not sold by g10code, but by kernel concepts. Thanks, Marcus From martin at martinpaljak.net Tue Aug 16 16:49:19 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Tue, 16 Aug 2011 17:49:19 +0300 Subject: [rant] using a hardware token with GnuPG In-Reply-To: <4E4A4334.5090702@ruhr-uni-bochum.de> References: <4E491862.6060906@martinpaljak.net> <4E4A4334.5090702@ruhr-uni-bochum.de> Message-ID: Hello, On Aug 16, 2011, at 1:15 , Marcus Brinkmann wrote: > gpg-agent is an integral part of any gnupg 2 environment. It should be > started as part of your session and be visible to all programs within it. I've understood that it is started automagically or at least not necessary for everything. I was able to sign with gpg2 without an agent running. > BTW, the OpenPGP cards are not sold by g10code, but by kernel concepts. Sorry, you are correct. I did not mean directly sold, but "the one referenced from/created by g10code" [1] [1] http://g10code.com/p-card.html -- @MartinPaljak.net +3725156495 From wk at gnupg.org Tue Aug 16 17:42:36 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Aug 2011 17:42:36 +0200 Subject: [rant] using a hardware token with GnuPG In-Reply-To: (Martin Paljak's message of "Tue, 16 Aug 2011 17:49:19 +0300") References: <4E491862.6060906@martinpaljak.net> <4E4A4334.5090702@ruhr-uni-bochum.de> Message-ID: <87d3g5747n.fsf@vigenere.g10code.de> On Tue, 16 Aug 2011 16:49, martin at martinpaljak.net said: > I've understood that it is started automagically or at least not necessary for everything. I was able to sign with gpg2 without an agent running. gpg2 stated the agent for you. Unless you used --use-standard-socket the agent was terminated right after the operation. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri Aug 19 08:49:09 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 19 Aug 2011 08:49:09 +0200 Subject: Program announce: gpgkeymgr In-Reply-To: References: Message-ID: <201108190849.10105.bernhard@intevation.de> Michael, Am Montag, 15. August 2011 18:46:16 schrieb Michael Florian Sch?nitzer: > http://nudin.github.com/GnuPGP-Tools/ thanks for creating Free Software and for helping email cryptography! I am wondering how the name GnuPGP tools came to be, you write they are for GnuPG and if you wanted to use a standard OpenPGP would probably be the one. Just wondering? -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Fri Aug 19 08:52:49 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 19 Aug 2011 08:52:49 +0200 Subject: Future for GnuPG 1.4.x for Windows In-Reply-To: <521014543.20110807125743@gmail.com> References: <521014543.20110807125743@gmail.com> Message-ID: <201108190852.50064.bernhard@intevation.de> Am Sonntag, 7. August 2011 12:57:43 schrieb Martin Schoch: > I am using GnuPG 1.4.11 on several Windows systems and I have now a > question about future development of GnuPG: > > On the Website of GnuPG.org the link for binaries for Windows goes now > to gpg4win Website. Gpg4win contains the official binaries of GnuPG for windows. I think 1.4.x will work, but I wouldn't recommend it in the general case. The stable 2.0.x is much more suited for use on Windows operation systems. > But I don't want to download the whole package gpg4win and I don't > want to install gnupg 2.x. During installation you can choose to only install a subset of what is within the package. Note that development of GnuPG for windows especially depends on funding, which currently is lacking, so the future of any maintained GnuPG port for windows is doubtful if this funding cannot be found. Best Regards, Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ml at schoenitzer.de Wed Aug 24 14:37:47 2011 From: ml at schoenitzer.de (Michael Florian =?iso-8859-1?q?Sch=F6nitzer?=) Date: Wed, 24 Aug 2011 12:37:47 +0000 (UTC) Subject: Program announce: gpgkeymgr References: <201108190849.10105.bernhard@intevation.de> Message-ID: [Note: this message has before accidentally been sent to Bernhard Reitner private and I was on vacation, so I didn't saw my mistake.] > thanks for creating Free Software and for helping email cryptography! Thanks. > I am wondering how the name GnuPGP tools came to be, you write they are for > GnuPG and if you wanted to use a standard OpenPGP would probably be the one. > Just wondering? Jeah, I mixed up GnuPG and PGP, so the right name would be GnuPG-Tools. But it's only the name of the repo ? maybe I'm going to rename it, or more likely I'm going to create a new Githup-Account "GnuPG-Tools" and make one repo for each program ? that would also making it easier to release & package version, etc. I'm open for ideas, including alternative names? Michi -- Michael F. Sch?nitzer Mail: michael ?t schoenitzer.de Homepage: http://www.schoenitzer.de Jabber: Schoenitzer at jabber.piratenpartei.de From chris at boyle.name Thu Aug 25 23:11:39 2011 From: chris at boyle.name (Chris Boyle) Date: Thu, 25 Aug 2011 22:11:39 +0100 Subject: OpenPGP card: verify or set a PIN -> "Conditions of use not satisfied" (69 85) Message-ID: Hi, I'm not sure whether this is a GPG problem as such (and if not, I would appreciate a pointer to a suitable list), but I just received an OpenPGP v2 card today from Kernel Concepts and am encountering "Conditions of use not satisfied" when trying to verify or change either of the PINs. An example log, trying to verify the default admin PIN, is: scdaemon[11914]: chan_7 -> INQUIRE NEEDPIN |A|Please enter the Admin PIN scdaemon[11914]: chan_7 <- [ 44 20 31 32 33 34 35 36 37 38 00 00 00 00 00 00 ...(76 byte(s) skipped) ] scdaemon[11914]: chan_7 <- END 2011-08-25 21:49:08 scdaemon[11914] DBG: send apdu: c=00 i=20 p1=00 p2=83 lc=8 le=-1 em=0 2011-08-25 21:49:08 scdaemon[11914] DBG: raw apdu: 00 20 00 83 08 31 32 33 34 35 36 37 38 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: dwLength ..........: 13 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSlot .............: 0 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSeq ..............: 204 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bBWI ..............: 0x04 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: wLevelParameter ...: 0x0000 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0010] 00 20 00 83 08 31 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0016] 32 33 34 35 36 37 38 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: RDR_to_PC_DataBlock: 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: dwLength ..........: 2 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSlot .............: 0 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSeq ..............: 204 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bStatus ...........: 0 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0010] 69 85 2011-08-25 21:49:08 scdaemon[11914] DBG: response: sw=6985 datalen=0 2011-08-25 21:49:08 scdaemon[11914] verify CHV3 failed: Conditions of use not satisfied scdaemon[11914]: chan_7 -> ERR 100663427 Conditions of use not satisfied The only discussions I could find of people seeing this error in this situation were where people had deny-admin set, which I don't. The reader is a Vasco DP855 which I received new a few days ago. I have no other reader. I have tried the reset-to-factory-defaults file, which did not change my results. Does anyone have any idea what might cause this response? I looked at the OpenPGP v2 spec and it just mentioned it as a possible error, not causes. Thanks, -- Chris Boyle http://chris.boyle.name/ From achim at pietig.com Fri Aug 26 09:30:21 2011 From: achim at pietig.com (Achim Pietig) Date: Fri, 26 Aug 2011 09:30:21 +0200 Subject: OpenPGP card: verify or set a PIN -> "Conditions of use not satisfied" (69 85) In-Reply-To: References: Message-ID: <4E574B8D.4070606@pietig.com> Hi, the error is strange and not easy to debug. An error code of 6985 never occurs in the VERIFY function of an OpenPGP card. The error can only occur in the command CHANGE REFERENCE DATA or RESET RETRY COUNTER, when a new password is too short or too long. The raw command is correct: > 2011-08-25 21:49:08 scdaemon[11914] DBG: raw apdu: 00 20 00 83 08 31 32 33 34 35 36 37 38 Hint: It is necessary to select the OpenPGP application with the SELECT command and the correct AID before sending any commands. Possible reasons for this error: - The driver/reader changes bytes/bits of the APDU und the card receives not what is shown in your debug. - The card is damaged (internal pointer error that jumps into the wrong function). - The card has an production/personalisation error. - It is not an OpenPGP card. Regards, Achim Am 25.08.2011 23:11, schrieb Chris Boyle: > Hi, I'm not sure whether this is a GPG problem as such (and if not, I > would appreciate a pointer to a suitable list), but I just received an > OpenPGP v2 card today from Kernel Concepts and am encountering > "Conditions of use not satisfied" when trying to verify or change > either of the PINs. An example log, trying to verify the default admin > PIN, is: > > scdaemon[11914]: chan_7 -> INQUIRE NEEDPIN |A|Please enter the Admin PIN > scdaemon[11914]: chan_7 <- [ 44 20 31 32 33 34 35 36 37 38 00 00 00 00 > 00 00 ...(76 byte(s) skipped) ] > scdaemon[11914]: chan_7 <- END > 2011-08-25 21:49:08 scdaemon[11914] DBG: send apdu: c=00 i=20 p1=00 > p2=83 lc=8 le=-1 em=0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: raw apdu: 00 20 00 83 08 31 > 32 33 34 35 36 37 38 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: PC_to_RDR_XfrBlock: > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: dwLength ..........: 13 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSlot .............: 0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSeq ..............: 204 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bBWI > ..............: 0x04 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: > wLevelParameter ...: 0x0000 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0010] 00 20 > 00 83 08 31 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0016] 32 33 > 34 35 36 37 38 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: RDR_to_PC_DataBlock: > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: dwLength ..........: 2 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSlot .............: 0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSeq ..............: 204 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bStatus ...........: 0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0010] 69 85 > 2011-08-25 21:49:08 scdaemon[11914] DBG: response: sw=6985 datalen=0 > 2011-08-25 21:49:08 scdaemon[11914] verify CHV3 failed: Conditions of > use not satisfied > scdaemon[11914]: chan_7 -> ERR 100663427 Conditions of use not satisfied > > The only discussions I could find of people seeing this error in this > situation were where people had deny-admin set, which I don't. > > The reader is a Vasco DP855 which I received new a few days ago. I > have no other reader. I have tried the reset-to-factory-defaults file, > which did not change my results. > > Does anyone have any idea what might cause this response? I looked at > the OpenPGP v2 spec and it just mentioned it as a possible error, not > causes. > > Thanks, From wk at gnupg.org Fri Aug 26 15:13:11 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Aug 2011 15:13:11 +0200 Subject: Translation of GnuPG Tools descriptions In-Reply-To: (Yuri Chornoivan's message of "Sun, 14 Aug 2011 12:52:20 +0300") References: Message-ID: <877h60tixk.fsf@vigenere.g10code.de> On Sun, 14 Aug 2011 11:52, yurchor at ukr.net said: > Tools descriptions in /tools/gpgconf-comp.c are addressed to NULL PO > domain name, not extracted and so untranslatable: > { "gpg", NULL, "GPG for OpenPGP", gc_options_gpg }, > Is this done on purpose? I guess not. If the same string is used somewhere else in GnuPG it will be translated anyway. I'll mark them for translation in 2.1. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From achim at pietig.com Fri Aug 26 15:45:13 2011 From: achim at pietig.com (Achim Pietig) Date: Fri, 26 Aug 2011 15:45:13 +0200 Subject: OpenPGP card: verify or set a PIN -> "Conditions of use not satisfied" (69 85) In-Reply-To: References: Message-ID: <4E57A369.6080407@pietig.com> Hi, I just checked your reader, it is a PIN-PAD. These devices may have a mode that they trace the APDUs for a PIN command and try to redirect it to the keyboard and display. It is possible that this reader recognizes the 0020 command, but cannot interprete the data (no banking format e.g.). In that case the error 6985 comes from the reader itself... Regards, Achim Am 25.08.2011 23:11, schrieb Chris Boyle: > Hi, I'm not sure whether this is a GPG problem as such (and if not, I > would appreciate a pointer to a suitable list), but I just received an > OpenPGP v2 card today from Kernel Concepts and am encountering > "Conditions of use not satisfied" when trying to verify or change > either of the PINs. An example log, trying to verify the default admin > PIN, is: > > scdaemon[11914]: chan_7 -> INQUIRE NEEDPIN |A|Please enter the Admin PIN > scdaemon[11914]: chan_7 <- [ 44 20 31 32 33 34 35 36 37 38 00 00 00 00 > 00 00 ...(76 byte(s) skipped) ] > scdaemon[11914]: chan_7 <- END > 2011-08-25 21:49:08 scdaemon[11914] DBG: send apdu: c=00 i=20 p1=00 > p2=83 lc=8 le=-1 em=0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: raw apdu: 00 20 00 83 08 31 > 32 33 34 35 36 37 38 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: PC_to_RDR_XfrBlock: > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: dwLength ..........: 13 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSlot .............: 0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSeq ..............: 204 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bBWI > ..............: 0x04 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: > wLevelParameter ...: 0x0000 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0010] 00 20 > 00 83 08 31 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0016] 32 33 > 34 35 36 37 38 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: RDR_to_PC_DataBlock: > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: dwLength ..........: 2 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSlot .............: 0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bSeq ..............: 204 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: bStatus ...........: 0 > 2011-08-25 21:49:08 scdaemon[11914] DBG: ccid-driver: [0010] 69 85 > 2011-08-25 21:49:08 scdaemon[11914] DBG: response: sw=6985 datalen=0 > 2011-08-25 21:49:08 scdaemon[11914] verify CHV3 failed: Conditions of > use not satisfied > scdaemon[11914]: chan_7 -> ERR 100663427 Conditions of use not satisfied > > The only discussions I could find of people seeing this error in this > situation were where people had deny-admin set, which I don't. > > The reader is a Vasco DP855 which I received new a few days ago. I > have no other reader. I have tried the reset-to-factory-defaults file, > which did not change my results. > > Does anyone have any idea what might cause this response? I looked at > the OpenPGP v2 spec and it just mentioned it as a possible error, not > causes. > > Thanks, From wk at gnupg.org Fri Aug 26 15:52:29 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Aug 2011 15:52:29 +0200 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: (Martin Paljak's message of "Thu, 11 Aug 2011 16:53:43 +0300") References: <8739h8s8y9.fsf@vigenere.g10code.de> <87ty9oqffi.fsf@vigenere.g10code.de> Message-ID: <8739goth42.fsf@vigenere.g10code.de> On Thu, 11 Aug 2011 15:53, martin at martinpaljak.net said: > Even though "assumption is the mother of all screw ups", the card is > mostly used to access cryptographic keys. Verifying the cryptographic > integrity if the response from the card is far better and meaningful > than tracking "card state". It is not about integrity but about user experience. For example if we know that we did a verify we don't need to ask the user for the a PIN. Sure we could also try to do it without a a verify and only ask for the PIN if the operation failed. It turned out that the way we do it now is much more user friendly. > Define "changed the card's state" ? There's SCARD_W_RESET_CARD. I know See above. > that this is probably not what you mean, but still. > Also, I don't know how GnuPG works on Windows, but I doubt it is easy > or even possible to change the way Windows PC/SC service works. PC/SC under Windows does the same as pcsclite - no problem at all. > OpenSC also used to have "static numbering of connected readers" but > this has proven to be inefficient in current environments as (well, > mostly for PKCS#11 based applications, more established platforms > (Windows, OS X) have their own frameworks) We do this for years without any problems (at least for the few who use more than one reader); we merely did not implement the list feature. >> I have no problems with PC/SC; I merely suggest to loop PC/SC access >> through scdaemon ;-) > > You mean using scdaemon+its CCID driver instead of libccid? Why? Any No, I mean using pc/sc - it is actually what GnuPG does on Windows and on Unix if it is not possible to use the internal driver. As said before: the internal CCID driver was needed because we had CCID readers but no support for them in pcsclite. I like to keep it because it removes an unnecessary library and daemon dependency and actually allow the use of readers which are not supported by libccid (old SCR335). > Accessing smart cards is a low level thing. Much like accessing USB > devices. Or PCI cards. Or other external hardware. USB and PCI are different things. USB is for large parts a replacement of RS232 which has always been used directly from userland. Thus using an USB port directly from userland is a clean way of engineering. > Yes, one of the things missing in Linux is a "central service" (a > daemon) that manages the "more meaningful" higher level access to > smart cards (Tokend on OS X/Minidriver in Windows) and it stems from > the lack of an agreed-upon framework in Linux. There would be I am not talking about a certain operating system kernel. GnuPG is not related to Linux; I for example use it with *BSD all the time. You may view scdaemon/gpg-agent as this central service. > The same way it would make sense to support PKCS#11 and let the user > decide what he/she wants to risk with - either using his keys with a > proprietary (or free!) PKCS#11 stack with GnuPG or being forced to the pkcs#11 does not make any sense at all. It is a kludge to support the ugluy NSS based applications. > While I feel your concern for open specs (OpenSC has many open source > drivers with no public docs at the same time), but there's a Most of the core OpenSC code is (was?) about creating card applications and not about accessing cards. The whole pkcs#15 business in OpenSC is way to complicated for accessing pkcs#15 cards; you don't need all the additional layers and the often unconsciously changed ABI. PKCS#15 was once established with the idea to make card access easy and uniform. It does not work, but that's a different story. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Sat Aug 27 19:41:34 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Sat, 27 Aug 2011 20:41:34 +0300 Subject: OpenPGP card: verify or set a PIN -> "Conditions of use not satisfied" (69 85) In-Reply-To: <4E57A369.6080407@pietig.com> References: <4E57A369.6080407@pietig.com> Message-ID: Hello, On Aug 26, 2011, at 4:45 , Achim Pietig wrote: > I just checked your reader, it is a PIN-PAD. These devices may have a mode that they trace the APDUs for a PIN command > and try to redirect it to the keyboard and display. > It is possible that this reader recognizes the 0020 command, but cannot interprete the data (no banking format e.g.). > In that case the error 6985 comes from the reader itself? I *hope* not (but as I don't have the reader I can't confirm it) Readers are not supposed to interpret plain VRIFY commands unless they implement "firewalling", which forbids host-provided PIN related commands and requires the use of the pin pad. To enable pinpad, a special block is needed which enables the secure PIN entry. Even if it was interpreting VERIFY commands, I wish it did not return this SW ? (something from the related PC/SC spec SW range 0x64XX should be used instead) You can try by sending an otherwise invalid VERIFY command to the card or some other card and see if it returns something different. Try for example the same command with a VISA card, you can then see if it comes from the reader or card. -- @MartinPaljak.net +3725156495 From martin at martinpaljak.net Tue Aug 30 14:04:25 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Tue, 30 Aug 2011 15:04:25 +0300 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: <8739goth42.fsf@vigenere.g10code.de> References: <8739h8s8y9.fsf@vigenere.g10code.de> <87ty9oqffi.fsf@vigenere.g10code.de> <8739goth42.fsf@vigenere.g10code.de> Message-ID: <4E5CD1C9.1080506@martinpaljak.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, On 26/08/11 16:52, Werner Koch wrote: > On Thu, 11 Aug 2011 15:53, martin at martinpaljak.net said: It is not > about integrity but about user experience. For example if we know > that we did a verify we don't need to ask the user for the a PIN. > Sure we could also try to do it without a a verify and only ask for > the PIN if the operation failed. It turned out that the way we do > it now is much more user friendly. User friendly would be if me as a user could use the card with the applications I chose, instead of being locked out totally for reasons mentioning either "security" (common in OpenSC camp) or "usability" (your argument). In fact it sounds more like KDE vs GNOME and who is more "right" in the way a desktop should be built. The most stupid thing is that users suffer while developers build walled gardens. >> Define "changed the card's state" ? There's SCARD_W_RESET_CARD. I >> know > > See above. You asked for "notification from pcscd when an application has changed the card's state". PC/SC defines SCARD_W_RESET_CARD, is this what you mean with a "card state change" ? Or something in the SCARD_STATE_* range? This is real and available, if this is OK, why don't you use it? If not, what exactly should be signalled ? > >> that this is probably not what you mean, but still. Also, I don't >> know how GnuPG works on Windows, but I doubt it is easy or even >> possible to change the way Windows PC/SC service works. > > PC/SC under Windows does the same as pcsclite - no problem at all. See above. I think what you have in mind is signalling on another level than PC/SC is designed to operate. PC/SC can not (SHOULD NOT) know which APDU-s change the logical card state, that is meaningful to scdaemon. PC/SC in the incarnation it exists in pcsc-lite is quite low level. If you were interested in extending an existing pcsclite API, you could look at the rest of the SCa The best way to rd* API from pcscworkgroup^?^H^H^H^H^H^HMicrosoft, which deals with more higher level "smart card mangling" with card groups and files and whatnot. I don't have strong belief in the non-low-level PC/SC calls either. If the state chnages present in pcsclite are not enough, fixes in Windows world is almost impossible without monkeypatching. Which makes them not worth it. >> OpenSC also used to have "static numbering of connected readers" >> but this has proven to be inefficient in current environments as >> (well, mostly for PKCS#11 based applications, more established >> platforms (Windows, OS X) have their own frameworks) > > We do this for years without any problems (at least for the few who > use more than one reader); we merely did not implement the list > feature. Probably you then have quite static setups, even if you use multiple readers. Right now what I have to do is plug out all "non-permanent" readers, plug in the device and re-run gpg(2) to have success without requiring an always changing command line option or configuration file change. > >>> I have no problems with PC/SC; I merely suggest to loop PC/SC >>> access through scdaemon ;-) >> >> You mean using scdaemon+its CCID driver instead of libccid? Why? >> Any > > No, I mean using pc/sc - it is actually what GnuPG does on Windows > and on Unix if it is not possible to use the internal driver. As > said before: the internal CCID driver was needed because we had > CCID readers but no support for them in pcsclite. I like to keep > it because it removes an unnecessary library and daemon dependency > and actually allow the use of readers which are not supported by > libccid (old SCR335). Sure, why not. In fact, the internal CCID driver might be useful on resource-constrained (embedded) platforms running gpg only. For the rest of scenarios, there should be enough reasons for allowing multiple consumers to access a single hardware device (reader and/or card) in a multi-application desktop environment. Through PC/SC, as this is what the rest of the world uses (to my knowledge) to access smart cards. >> Yes, one of the things missing in Linux is a "central service" >> (a daemon) that manages the "more meaningful" higher level access >> to smart cards (Tokend on OS X/Minidriver in Windows) and it >> stems from the lack of an agreed-upon framework in Linux. There >> would be > > I am not talking about a certain operating system kernel. GnuPG is > not related to Linux; I for example use it with *BSD all the time. > You may view scdaemon/gpg-agent as this central service. Disregard Linux and read it as "popular open source Unices". What I mean is the absence of an API/library/daemon/component that would be deployed and advocated and developed as "the alpha and omega of cryptography for Unices" and that would actually take into account meaningful hardware access, with the special case of smart cards and readers (which is much more dynamic target than a dedicated HSM in that matter) Windows has CryptoAPI and applications written against it claim "platform support for smart cards and other cryptographic hardware" by default. OS X up to now used to have KeychainServices/CDSA/Tokend mess (with the Tokend being the equivalent of scdaemon for smart cards) which native OS X applications use(d) to get access to software certificates, trust services and also compliant smart cards (heck, there was even a Tokend bridge for PKCS#11 devices, which could be used throgh the PKCS#11 module provided by OS X for Tokend devices.. very meta). Linux^H^H^H^HUnices on the other hand have OpenSSL, NSS, ssh-agent, gpg-agent, pcscd+ccid, PKCS#11, gnutls, OpenSC, ... Fedora folks think that "NSS should be the central service for everything crypto" and have the "crypto consolidation effort" [1]. Many revolt for obvious reasons, as it limits their options. Will it come to Debian? I doubt it. The problem of all those little libraries dealing with (software) crypto in Unices or otherwise portable software is that it omits the platform specific parts that deal with accessing hardware devices in an pleaseant and user-friendly manner (the prominent user of PKCS#11, Mozilla, has demonstrated that PKCS#11 directly is not a friendly create. This is something p11-kit [2] should help to remedy) Claiming any single vendor-defined interface with a single implementation to be the de facto "central service" in an open environment is not a smart move. Microsoft can do it and Apple can do whatever they want, as application developers are forced to integrate with their tools and platform if they want to succeed. That's why OpenSSL (engine) fails, NSS as a forced library fails (even though it can use PKCS#11 which should be a good sign), gpg-agent fails and ssh-agent fails. And PKCS#11 wins IMHO. ("Opinions are like assholes. Everybody's got one and everyone thinks everyone else's stinks." [3]) I really wish there was one that dealt with the basics: providing access to *keys* and leaving the rest out. For this to succeed, Linux folks need to agree on the lowest level, as everything else would be like K vs G or PGP vs X509 debate. I don't want to be forced G-everything or K-everything stack to get a meaningful experience, I'd like to choose what I want to use. >> The same way it would make sense to support PKCS#11 and let the >> user decide what he/she wants to risk with - either using his >> keys with a proprietary (or free!) PKCS#11 stack with GnuPG or >> being forced to the > > pkcs#11 does not make any sense at all. It is a kludge to support > the ugluy NSS based applications. Sorry, I don't buy that. PKCS#11 makes *much* sense in *many* applications having zero need for or knowledge of NSS. Take OpenSSH - last time I checked could use PKCS#11 without requiring NSS. PKCS#11 is far from perfect, but it is the only cross-platform, "stable" API which developers on Unices can use wihout falling for the "K" vs "G" debate common in Linux. Which is much less productive than embracing *something* as a common solution and building upon it. The goal here is not to point fingers telling who is more ugly or more wrong, but to get to a point where user has the power (enough to be a poweruser without the risk of shooting himself in the leg with a bazooka) to choose the application stack with the hardware at hand. >> While I feel your concern for open specs (OpenSC has many open >> source drivers with no public docs at the same time), but there's >> a > > Most of the core OpenSC code is (was?) about creating card > applications and not about accessing cards. The whole pkcs#15 > business in OpenSC is way to complicated for accessing pkcs#15 > cards; you don't need all the additional layers and the often > unconsciously changed ABI. OpenSC consists of two major parts at the core: - PKCS#15 structure creating for cards that can be personalized ("creating applications") - Decoding PKCS#15 structures and synthesising PKCS#15-ish structures for cards that don't implement it (like OpenPGP or Estonian eID cards) to provide access to on-card keys. The ratio of different drivers, especially when taking into account number of cards in use, is probably strongly for read-only cards. The other big parts of OpenSC are platform specific API-s like Tokend for OS X or a Minidriver for Windows, that enable to use the smart cards supported by OpenSC in the most convenient manner on a given platform. About ABI: libopensc as a library has been deprecated for the reasons of not having a well designed API with the right level of abstraction and documentation in the first place and because there is a better option available for 99% applications (that want to use OpenSC to access on-card keys): PKCS#11. libopensc as an API for "standard for smart card access" was anyway doomed to fail for the same reasons as NSS/OpenSSL would fail. > PKCS#15 was once established with the idea to make card access easy > and uniform. It does not work, but that's a different story. Unfortunately I have to agree to some extent, but again - that is a totally different story. Coming back to the questions in my original e-mail, my intent is not to just flame as hell but to fix the issue(s). * How could I help to debug the the problem, so that I could use gpg2 for decryption. Would a debug log with max verbose settings help? * If I was to "fix" (in my terms) the problems with scdaemon: - selecting a suitable reader automagically without configuration file/command line changes - locking the reader only when it is in fact used (for encryption/decryption) how should I continue? Should I fix gpg or gpg2? Or both? What is the relation between gpg1 and gpg2 codebases? Some general pointers would suffice, I've done some homework but probably not enough to succeed at once. Best, Martin [1] http://fedoraproject.org/wiki/FedoraCryptoConsolidation [2] http://p11-glue.freedesktop.org/p11-kit.html [3] http://www.imdb.com/title/tt0113321/quotes?qt=qt0492371 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOXNHCAAoJEHSCZV4wfjRSqeYP/1A+DrBIhfuxvKGNKqRRNBaX 8okVmVPlFSq3uyBDOUgfQfqoIPktdZgFjJ+MpBBUwgxnpnjJv8lP6+cDILM4zgxl kKsg1DDT8fnL4KFiaLc/4Drc2xYOahzbvon7KVfzaToQjQZnYAYyNziMgZ5RlCml PErnM+xyzbMV9lZYTDkfHJIF5XBlBabMI6fkwGHG0Z7cwWmyRIpooKaFV9Vt5HO1 rQkvEc3pcdS4WeKPovxw1XM6dFYmYxEpmWJaZ2w/9qn8IMsoSoO/ToQKkSRlz1Tz oTjSAIMqR90G9OmR7IDQXAOIq3oTUqBRlkZEXuRZKR70zT64X7nbcHjOl7rETGGg qS32dgNlKwDBhFRSdJ39MMqyugRotGGNclW8cY/Nydr22V2vvf2+G2HQfj3yXipq +wF4owYyL7dMdfbvh0W/KuiKh+4rFi+DL/0oZ+xvZ3Rc0eUy195lGIoycFgfK8xo 301ewinE1EFqfZ6rZZuN/8PhpX12ZGAE0xcdjMxu4mrtDq+AdBexaDI32urAytBF jp0aVKvVTuamLisi7Dk1Ez1tKpk0rkHnwz0oHaWDbbYA7oboEkoU4HI77RjURY3g UtPCF7XQllFe9bgBQ8yfSX7g1nNArQtnHQHe2Kutf7BgZSUhGI+177JHNENhk/ww o5YvelNejQUdH/xPNSwE =iRma -----END PGP SIGNATURE----- From wk at gnupg.org Tue Aug 30 18:17:35 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Aug 2011 18:17:35 +0200 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: <4E5CD1C9.1080506@martinpaljak.net> (Martin Paljak's message of "Tue, 30 Aug 2011 15:04:25 +0300") References: <8739h8s8y9.fsf@vigenere.g10code.de> <87ty9oqffi.fsf@vigenere.g10code.de> <8739goth42.fsf@vigenere.g10code.de> <4E5CD1C9.1080506@martinpaljak.net> Message-ID: <871uw2ri00.fsf@vigenere.g10code.de> On Tue, 30 Aug 2011 14:04, martin at martinpaljak.net said: > User friendly would be if me as a user could use the card with the > applications I chose, instead of being locked out totally for reasons Card applications or host applications? For the former you merely need to write an app-foo module to scdaemon. For the latter you may use the provided api or if you want pkcs#11, use scute. > You asked for "notification from pcscd when an application has changed > the card's state". PC/SC defines SCARD_W_RESET_CARD, is this what you No, any write/put/verify/etc operation. Right this means that pc/sc would need to interpret the APDUs; thus it is likely that it needs to send notify us most of the time. > See above. I think what you have in mind is signalling on another > level than PC/SC is designed to operate. PC/SC can not (SHOULD NOT) > know which APDU-s change the logical card state, that is meaningful to Agreed. > which deals with more higher level "smart card mangling" with card > groups and files and whatnot. I don't have strong belief in the Well, we agree here. Microsoft uses mini drivers, GnuPG uses scdaemon. > Probably you then have quite static setups, even if you use multiple > readers. Right now what I have to do is plug out all "non-permanent" No problem as long as all readers have different names. Beware of bugs - it is probably not well tested because I always suggest the use of the internal driver. > For the rest of scenarios, there should be enough reasons for allowing > multiple consumers to access a single hardware device (reader and/or > card) in a multi-application desktop environment. Through PC/SC, as Just configure the timeout value and it works. > Disregard Linux and read it as "popular open source Unices". GnuPG is also used on proprietary Unices. > Linux^H^H^H^HUnices on the other hand have OpenSSL, NSS, ssh-agent, > gpg-agent, pcscd+ccid, PKCS#11, gnutls, OpenSC, ... You are mixing something: - NSS and GnuPG are systems with very similar goals. In particular they their usual use cases require a user interface. - GNUTLS is a high level TLS library - Pcscd is a low-evel hardware abstraction library. - OpenSC is a high level card application abstraction library. - PKCS#11 is an API - ssh-agent and gpg-agent are parts of larger systems (GnuPG and SSH) > Fedora folks think that "NSS should be the central service for > everything crypto" and have the "crypto consolidation effort" [1]. Because Redhat needs FIPS 140 validation for RHEL and once they decided that the easiest way to do this is by using the already FIPS validated NSS. > Claiming any single vendor-defined interface with a single > implementation to be the de facto "central service" in an open > environment is not a smart move. Microsoft can do it and Apple can do It is about free software and not about vendors. At least for the GNU project using GnuPG seems to be a very good choice. > though it can use PKCS#11 which should be a good sign), gpg-agent > fails and ssh-agent fails. And PKCS#11 wins IMHO. Sorry, you can't compare gpg-agent and ssh-agent - see above. > like K vs G or PGP vs X509 debate. I don't want to be forced > G-everything or K-everything stack to get a meaningful experience, I'd > like to choose what I want to use. So what is the problem? After all it is Free Software and nobody will tell you what you are supposed to do with it. This is freedom #0. > Sorry, I don't buy that. PKCS#11 makes *much* sense in *many* > applications having zero need for or knowledge of NSS. > Take OpenSSH - last time I checked could use PKCS#11 without requiring Right, it makes a lot of sense to them. A stated goal of OpenSSH is to allow the use by proprietary systems. Thus they do everything to make proprietary software vendors happy; i.e. use an pkcs#11 interface. Checkout who works on OpenSSH and what they do for a living. > PKCS#11 is far from perfect, but it is the only cross-platform, > "stable" API which developers on Unices can use wihout falling for the Well, Microsoft doesn't use it anymore. > "K" vs "G" debate common in Linux. Which is much less productive than I am not using any of these desktops. I would never tie software I maintain to one specific desktop GUI. > About ABI: libopensc as a library has been deprecated for the reasons > of not having a well designed API with the right level of abstraction > and documentation in the first place and because there is a better The reasons was more that OpenSC used to be a collection of smart card related code with no common idea what to build. I participated in the early OpenSC development but turned away for this reason and because of bad software maintenance style (API and ABIs changes at will). > * How could I help to debug the the problem, so that I could use gpg2 > for decryption. Would a debug log with max verbose settings help? So what was the problem? The card code in master needs some work; there are some things which have not yet been implemented and we have not ported changes from 2.0. > * If I was to "fix" (in my terms) the problems with scdaemon: > - selecting a suitable reader automagically without configuration > file/command line changes You mean the default reader should be the reader which most likely supports most cards. I.e. kick out all Omnicard and possible cheap internal readers? > - locking the reader only when it is in fact used (for > encryption/decryption) Better use the timeout option. If the timeout option should be enabled by default we should discuss this. If it works for more users better than we should enable it. > how should I continue? Should I fix gpg or gpg2? Or both? What is the > relation between gpg1 and gpg2 codebases? Forget about gpg1 and cards - after all it uses an installed gpg-agent anyway before it falls back to the included code. Thus without a running gpg-agent it is does not grab the reader. We source copy files from 2.0 to 1.4; thus don't develop on the 1.4 branch. If you want to fix something card related you better look at the stable 2.0 branch for now. > Some general pointers would suffice, I've done some homework but > probably not enough to succeed at once. If you have problems feel free to ask; you may also jabber me (I use guug.de jabber address). If you want to write code, we need a copyright assignments to the FSF. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Wed Aug 31 08:06:35 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 31 Aug 2011 09:06:35 +0300 Subject: Peaceful coexistence of GnuPG and other smart card software In-Reply-To: <871uw2ri00.fsf@vigenere.g10code.de> References: <8739h8s8y9.fsf@vigenere.g10code.de> <87ty9oqffi.fsf@vigenere.g10code.de> <8739goth42.fsf@vigenere.g10code.de> <4E5CD1C9.1080506@martinpaljak.net> <871uw2ri00.fsf@vigenere.g10code.de> Message-ID: <4E5DCF6B.40900@martinpaljak.net> Hello, On 8/30/11 7:17 , Werner Koch wrote: > On Tue, 30 Aug 2011 14:04, martin at martinpaljak.net said: > >> User friendly would be if me as a user could use the card with the >> applications I chose, instead of being locked out totally for reasons > > Card applications or host applications? For the former you merely need > to write an app-foo module to scdaemon. For the latter you may use the > provided api or if you want pkcs#11, use scute. Both. I'm recently a small fan of the CryptoStick device (probably soon the OpenPGP v2 card as well, once I get to ordering some) generously donated by GPF because of the 4k keys but I also have a bunch of non-OpenPGP cards like national eID, which I'd like to use with GnuPG as subkeys for daily use for example Scute did not work for me. Eventually I'd anyway like to use OpenSC for PKCS#11 (and for OS X/Chrome for SSL and Mail.app for X509 S/MIME and Windows/Chrome for SSL). Also, scute suffers from the same lock-in problem as scdaemon. >> You asked for "notification from pcscd when an application has changed >> the card's state". PC/SC defines SCARD_W_RESET_CARD, is this what you > > No, any write/put/verify/etc operation. Right this means that pc/sc > would need to interpret the APDUs; thus it is likely that it needs to > send notify us most of the time. That's not provided by PC/SC and IMHO should not. Thus the approach of assuming unknown state from the card for every operation is justified and sounds like a reasonable approach. >> which deals with more higher level "smart card mangling" with card >> groups and files and whatnot. I don't have strong belief in the > > Well, we agree here. Microsoft uses mini drivers, GnuPG uses scdaemon. There are many more functions in the SCard* family that do not directly relate to implementing a Minidriver [1], at least not "externally" to people wishing to implement smart card support for Windows platform applications. The key here is that Microsoft/CryptoAPI is a more like a platform whereas GnuPG is an application. At least for me. I don't know any other "consumers" of GnuPG/scdaemon stack. So the aggressive resource grabbing of scdaemon is not justified IMHO. >> Probably you then have quite static setups, even if you use multiple >> readers. Right now what I have to do is plug out all "non-permanent" > > No problem as long as all readers have different names. Beware of bugs > - it is probably not well tested because I always suggest the use of the > internal driver. All readers do have different names and that is the problem. When hotplugging readers their names change, so it is not possible to have a fixed and always meaningful configuration. Compare to ethX ordering changing on bootup with early Linuxes (can't remember the details but the problem had similar symptoms) I'll classify this as a bug. >> For the rest of scenarios, there should be enough reasons for allowing >> multiple consumers to access a single hardware device (reader and/or >> card) in a multi-application desktop environment. Through PC/SC, as > > Just configure the timeout value and it works. Did not work for me, see my initial e-mail. scdaemon was kept running and locked the reader. Maybe I got so desperate and mixed up with gpg1/gpg2 that it was some kind of interference. I'll investigate one more time. In any case it could be made more user friendly by default (meaning less configuration needed for most uses). > >> Disregard Linux and read it as "popular open source Unices". > > GnuPG is also used on proprietary Unices. Disregard "open source" as well. I meant "popular Unices", ones that actually matter in connection with open source software or otherwise recent computing (I doubt AIX or HPUX really matters) The Unix problem is the Android problem (being Linux based) which is fragmentation. There is no such thing for 90% for Unices as there is for 90% of Windows boxes or 99% of OS X boxes for "platform crypto". There is no central API (like open() read() close()) that would deal with crypto that would be universal and shared between platforms and accepted and re-used by applications. There are xyz_CryptoInit() and foobar_init_crypto_stack() and MySecurityServicePKCS11Init() and whatnot, but they are not shared. So it is virtually impossible to create a solution that would take exclusive ownership of hardware devices like smart cards for the purpose of presenting them to the rest of the system. >> Linux^H^H^H^HUnices on the other hand have OpenSSL, NSS, ssh-agent, >> gpg-agent, pcscd+ccid, PKCS#11, gnutls, OpenSC, ... > > You are mixing something: > > - NSS and GnuPG are systems with very similar goals. In particular they > their usual use cases require a user interface. NSS is a quite generic crypto library which also implements a bunch of protocols like TLS. GnuPG on the other hand is mostly PGP and to me manifests itself mostly as a command line utility. NSS is more like OpenSSL, that by name should be a SSL library but happens to be the thing that people link against to get sha1... > - Pcscd is a low-evel hardware abstraction library. PC/SC is an API for accessing smart card readers and cards. > - OpenSC is a high level card application abstraction library. > - PKCS#11 is an API OpenSC and PKCS#11 fill the same goals: providing access to keys in hardware. OpenSC just happens to implement more interfaces than only PKCS#11 for accessing smart card type devices. > - ssh-agent and gpg-agent are parts of larger systems (GnuPG and SSH) You previously wanted to suggest that gpg-agent could be viewed as a "minidriver" replacement (meaning a provider for a broader platform) when yes, indeed, it is a part of an application. >> Fedora folks think that "NSS should be the central service for >> everything crypto" and have the "crypto consolidation effort" [1]. > > Because Redhat needs FIPS 140 validation for RHEL and once they decided > that the easiest way to do this is by using the already FIPS validated > NSS. Yes. It also gives some benefits like "maybe working hardware key machinery support" because of PKCS#11 support in NSS. But I hope that it does not spread outside of Redhat and I envision applications with several different backends [2]. >> Claiming any single vendor-defined interface with a single >> implementation to be the de facto "central service" in an open >> environment is not a smart move. Microsoft can do it and Apple can do > > It is about free software and not about vendors. At least for the GNU > project using GnuPG seems to be a very good choice. >> though it can use PKCS#11 which should be a good sign), gpg-agent >> fails and ssh-agent fails. And PKCS#11 wins IMHO. > > Sorry, you can't compare gpg-agent and ssh-agent - see above. My point is that tying hardware access, which belongs to a "platform" if anywhere at all, to a single implementation like gpg-agent/scdaemon is not optimal. I've probably made some reckless comparisons. >> Sorry, I don't buy that. PKCS#11 makes *much* sense in *many* >> applications having zero need for or knowledge of NSS. >> Take OpenSSH - last time I checked could use PKCS#11 without requiring > > Right, it makes a lot of sense to them. A stated goal of OpenSSH is to > allow the use by proprietary systems. Thus they do everything to make > proprietary software vendors happy; i.e. use an pkcs#11 interface. Is it such a bad goal? PKCS#11 seems a quite innocent approach compared to some other things that are happening on the "border of free and proprietary". It gets things done in practical environment so it should be encouraged. > Checkout who works on OpenSSH and what they do for a living. I don't know. Do you have pointers? Can't blame one for earning a living though... In the end we're all biased and have certain affiliations. I try to stick to common sense... >> PKCS#11 is far from perfect, but it is the only cross-platform, >> "stable" API which developers on Unices can use wihout falling for the > > Well, Microsoft doesn't use it anymore. Because they have something better and more meaningful for Windows. CryptoAPI. Nothing forbids applications from using PKCS#11 on Windows - there are plenty of providers available and there's a lot of specialized applications using PKCS#11 on Windows (HSM-s?), most are using specialized hardware anyway. Most "desktop applications" are better off using CryptoAPI. >> "K" vs "G" debate common in Linux. Which is much less productive than > > I am not using any of these desktops. I would never tie software I > maintain to one specific desktop GUI. My comparison was arbitrary, as it seems to me that you want to tie using OpenPGP cards to using GnuPG, by requiring the use of scdaemon for any other purposes and vice-verse, re-creating existing software (PKCS#11) to access existing hardware keys with GnuPG? >> About ABI: libopensc as a library has been deprecated for the reasons >> of not having a well designed API with the right level of abstraction >> and documentation in the first place and because there is a better > > The reasons was more that OpenSC used to be a collection of smart card > related code with no common idea what to build. I participated in the > early OpenSC development but turned away for this reason and because of > bad software maintenance style (API and ABIs changes at will). Yeah, being kitchen-sink has had its downsides. But as said, PKCS#11 fixes the API/ABI problem these days. OpenSSH used to have code that linked against libopensc and this has been abandoned for a good reason - it was a bad choice in the beginning. The purpose of OpenSC is much more focused right now: providing access for hardware keys on supported cards to as many applications as possible (and creating supported cards (personalizing) if possible) I actually think that OpenSC should be split/forked one more time, by creating an "OpenTMC" as "open token management center" that would add more pieces for token issuing and management, like being a secure messaging key manager (not a simple task either). Pure and simplistic PKCS#15 creation won't be enough in near time for practical use. >> * How could I help to debug the the problem, so that I could use gpg2 >> for decryption. Would a debug log with max verbose settings help? > > So what was the problem? The card code in master needs some work; there > are some things which have not yet been implemented and we have not > ported changes from 2.0. "key not found" when decrypting with gpg2 even though key gets listed OK but success with gpg1 (after setting the environment right for gpg, with OpenPGP card in first unused PC/SC reader) >> * If I was to "fix" (in my terms) the problems with scdaemon: >> - selecting a suitable reader automagically without configuration >> file/command line changes > > You mean the default reader should be the reader which most likely > supports most cards. I.e. kick out all Omnicard and possible cheap > internal readers? The default reader used by scdaemon when used through gpg/gpg-agent should be: - one that actually contains a card (not failing with "please insert a card" message, which should only be used if there is a static configuration or command line parameter) - one that contains a supported card (if I have reader A with a card not supported by GnuPG and reader B with an OpenPGP card, reader B should be used by default (or automagically)) >> - locking the reader only when it is in fact used (for >> encryption/decryption) > > Better use the timeout option. If the timeout option should be enabled > by default we should discuss this. If it works for more users better > than we should enable it. Did not work. Should be enabled. Will try again. With multiple applications a shared connection will always be open to the card from another application, so scdaemon must also not fail when it can't connect to reader in exclusive mode but use transactions instead. It can't assume exclusive access. >> how should I continue? Should I fix gpg or gpg2? Or both? What is the >> relation between gpg1 and gpg2 codebases? > > Forget about gpg1 and cards - after all it uses an installed gpg-agent > anyway before it falls back to the included code. Thus without a > running gpg-agent it is does not grab the reader. We source copy files > from 2.0 to 1.4; thus don't develop on the 1.4 branch. > > If you want to fix something card related you better look at the stable > 2.0 branch for now. OK. >> Some general pointers would suffice, I've done some homework but >> probably not enough to succeed at once. > > If you have problems feel free to ask; you may also jabber me (I use > guug.de jabber address). If you want to write code, we need a copyright > assignments to the FSF. OK. [1] http://msdn.microsoft.com/en-us/library/aa380144(v=VS.85).aspx [2] http://curl.haxx.se/docs/ssl-compared.html -- @MartinPaljak +3725156495