From gniibe at fsij.org Fri Mar 1 07:22:22 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 01 Mar 2013 15:22:22 +0900 Subject: OpenPGP card specification enhancement for ECDSA support Message-ID: <1362118942.6222.1.camel@cfw2.gniibe.org> Hello, This message is CC-ed to GnuPG-Devel List. I am currently extending GnuPG so that it will support OpenPGP card with ECDSA feature in future. So far, following two things are modifications to the current OpenPGP card specification. Could you please give me comments? (1) 4.3.3.6 Algorithm Attributes ECDSA: Byte Length Value 01 01 Algorithm ID (RFC6637) 13 = ECDSA 02- Variable OID (RFC6637) 2A 86 48 CE 3D 03 01 07 NIST curve P-256 2B 81 04 00 22 NIST curve P-384 2B 81 04 00 23 NIST curve P-521 I think that use of OID here would be best, since OID is used to identify the curve in OpenPGP ECC (RFC 6637). (2) 7.2.11 GENERATE ASYMMETRIC KEY PAIR Set of public key data objects for ECDSA 81 xx Public key In the format of uncompressed point: 04 || x || y where x and y are coordinate of the point P = (x, y). Big-endian, zero-padded. (c.f. Section 6. Conversion Primitives in RFC 6637) I think that curve specification (For example, Generator, Order, etc.) is defined by OID in the Algorithm Attributes, it's enough to return the public key, EC point, and it's natural to use standard encoding of uncompressed point. -- From openpgp at brainhub.org Fri Mar 1 20:02:18 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Fri, 01 Mar 2013 11:02:18 -0800 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <1362118942.6222.1.camel@cfw2.gniibe.org> References: <1362118942.6222.1.camel@cfw2.gniibe.org> Message-ID: <5130FB3A.7060307@brainhub.org> Hi NIIBE. Please consider using the compact representation of an ECC point: http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card. I plan to submit a relevant proposal to use the compact representation in OpenPGP. The benefit of the compact representation is that you will have to transmit less than half of bytes of the point over in the host-to-card protocol. For this compact representation of the ECC point to work one needs to slightly adjust the key generation. It's always possible to do so with the proposed method, even with any existing method that generates keys on the card (one uses "black box" approach in this case). The ideal scenario is when the key generation is already generating compliant keys. Thus, I suggest to change the key generation on the card to always return the compliant keys. IMO we should all generate compliant OpenPGP keys in the entire OpenPGP ecosystem (and beyond as well, as keys are sometimes migrated between PKI and OpenPGP). Well, at least compliant keys are within our reach at OpenPGP. ( I will say that it's unfortunate that RFC 6637 was specified to use SEC format 04 | x | y. The reason is that at the time I didn't know about all the benefits that a *single* format such as http://tools.ietf.org/html/draft-jivsov-ecc-compact would bring. I plan to remedy this with another draft. So, it's a heads up. Please consider not using the SEC format. ) Thank you. On 02/28/2013 10:22 PM, NIIBE Yutaka wrote: > Hello, > > This message is CC-ed to GnuPG-Devel List. > > I am currently extending GnuPG so that it will support OpenPGP card > with ECDSA feature in future. > > So far, following two things are modifications to the current OpenPGP > card specification. > > Could you please give me comments? > > > (1) 4.3.3.6 Algorithm Attributes > > ECDSA: > > Byte Length Value > 01 01 Algorithm ID (RFC6637) 13 = ECDSA > 02- Variable OID (RFC6637) > 2A 86 48 CE 3D 03 01 07 NIST curve P-256 > 2B 81 04 00 22 NIST curve P-384 > 2B 81 04 00 23 NIST curve P-521 > > I think that use of OID here would be best, since OID is used to > identify the curve in OpenPGP ECC (RFC 6637). > > > (2) 7.2.11 GENERATE ASYMMETRIC KEY PAIR > > Set of public key data objects for ECDSA > > 81 xx Public key > > In the format of uncompressed point: > > 04 || x || y > > where x and y are coordinate of the point P = (x, y). > Big-endian, zero-padded. > (c.f. Section 6. Conversion Primitives in RFC 6637) > > I think that curve specification (For example, Generator, Order, etc.) > is defined by OID in the Algorithm Attributes, it's enough to return > the public key, EC point, and it's natural to use standard encoding > of uncompressed point. > From dshaw at jabberwocky.com Fri Mar 1 23:46:53 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 1 Mar 2013 17:46:53 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130301222424.GA16681@redoubt.spodhuis.org> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> Message-ID: <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> On Mar 1, 2013, at 5:24 PM, Phil Pennock wrote: > On 2013-02-28 at 14:09 -0500, David Shaw wrote: >> Pretty easy case. All set. This isn't an issue on master, by the way. The logic is reversed on that branch so there is only a shutdown when specifically requested - and it isn't requested. > > In diagnosing whether a fix for this works, there's a problem that GnuPG > both retrieves a key and reports that it failed. > > I think that the shim is failing to set whatever flag is referenced as > ctx.flags.done in the gpgkeys_hkp.c code. > > ----------------------------8< cut here >8------------------------------ > % /usr/local/libexec/gpg2keys_hkp > COMMAND GET > HOST keys2.kfwebs.net > PORT 11371 > SCHEME hkp > > KEY 403043153903637F > > ----------------------------8< cut here >8------------------------------ > > Get: > KEY 0xKEY 403043153903637F BEGIN > * HTTP host:port post-SRV is "keys2.kfwebs.net:11371" > -----BEGIN PGP PUBLIC KEY BLOCK----- > [...] > m3QmaaAfDDkAn0EfIzN9wDIdYGM6p5eihu2vZAfIiGQEExECACQFCQWjmoACF4AGCwkIBwMC > gpgkeys: key KEY 403043153903637F not found on keyserver > AxUCAwMWAgECHgEFA > KEY 0xKEY 403043153903637F FAILED 6 > > In fact, the struct CURL's flags field from curl-shim.h doesn't include > a done field, so I'm not sure why this compiles. At least, when I look > at current git on the STABLE-BRANCH-2-0 branch. I think you are confused. The structure ctx is a struct curl_writer_ctx, not a struct CURL. It's defined in ksutil.h. Why did you put "KEY" in front of the key ID of the key? GPG doesn't do that. Aside from those two points, this works for me. You snipped most of the output, so the best guess I can give you is that for some reason you're missing the "-----END PGP PUBLIC KEY BLOCK-----". David From gnupg-devel at spodhuis.org Fri Mar 1 23:24:24 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Fri, 1 Mar 2013 17:24:24 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> Message-ID: <20130301222424.GA16681@redoubt.spodhuis.org> On 2013-02-28 at 14:09 -0500, David Shaw wrote: > Pretty easy case. All set. This isn't an issue on master, by the way. The logic is reversed on that branch so there is only a shutdown when specifically requested - and it isn't requested. In diagnosing whether a fix for this works, there's a problem that GnuPG both retrieves a key and reports that it failed. I think that the shim is failing to set whatever flag is referenced as ctx.flags.done in the gpgkeys_hkp.c code. ----------------------------8< cut here >8------------------------------ % /usr/local/libexec/gpg2keys_hkp COMMAND GET HOST keys2.kfwebs.net PORT 11371 SCHEME hkp KEY 403043153903637F ----------------------------8< cut here >8------------------------------ Get: KEY 0xKEY 403043153903637F BEGIN * HTTP host:port post-SRV is "keys2.kfwebs.net:11371" -----BEGIN PGP PUBLIC KEY BLOCK----- [...] m3QmaaAfDDkAn0EfIzN9wDIdYGM6p5eihu2vZAfIiGQEExECACQFCQWjmoACF4AGCwkIBwMC gpgkeys: key KEY 403043153903637F not found on keyserver AxUCAwMWAgECHgEFA KEY 0xKEY 403043153903637F FAILED 6 In fact, the struct CURL's flags field from curl-shim.h doesn't include a done field, so I'm not sure why this compiles. At least, when I look at current git on the STABLE-BRANCH-2-0 branch. -Phil From gnupg-devel at spodhuis.org Sat Mar 2 00:56:04 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Fri, 1 Mar 2013 18:56:04 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> Message-ID: <20130301235603.GA18897@redoubt.spodhuis.org> On 2013-03-01 at 17:46 -0500, David Shaw wrote: > I think you are confused. The structure ctx is a struct curl_writer_ctx, not a struct CURL. It's defined in ksutil.h. Crap, skimmed too quickly, sorry. > Why did you put "KEY" in front of the key ID of the key? GPG doesn't do that. Because I didn't spot documentation and didn't read the source in depth, I skimmed to get the minimal possible to try to figure out why, in normal use without invoking the helpers manually, the verbose/debug output was both showing a key and reporting that no key is found, for both myself and the other person tracking down the gnupg/keyserver interop issues. > Aside from those two points, this works for me. You snipped most of the output, so the best guess I can give you is that for some reason you're missing the "-----END PGP PUBLIC KEY BLOCK-----". The keys are retrieved, it's just that "--keyserver-options verbose,debug" erroneously reports that there's no key. The only thing slightly weird that I see is that SKS is returning an ASCII-armoured key with LF between each line, but ending the END PGP marker line with CRLF. -Phil From dshaw at jabberwocky.com Sat Mar 2 02:19:03 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 1 Mar 2013 20:19:03 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130301235603.GA18897@redoubt.spodhuis.org> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> Message-ID: On Mar 1, 2013, at 6:56 PM, Phil Pennock wrote: > On 2013-03-01 at 17:46 -0500, David Shaw wrote: >> I think you are confused. The structure ctx is a struct curl_writer_ctx, not a struct CURL. It's defined in ksutil.h. > > Crap, skimmed too quickly, sorry. > >> Why did you put "KEY" in front of the key ID of the key? GPG doesn't do that. > > Because I didn't spot documentation and didn't read the source in depth, > I skimmed to get the minimal possible to try to figure out why, in > normal use without invoking the helpers manually, the verbose/debug > output was both showing a key and reporting that no key is found, for > both myself and the other person tracking down the gnupg/keyserver > interop issues. > >> Aside from those two points, this works for me. You snipped most of the output, so the best guess I can give you is that for some reason you're missing the "-----END PGP PUBLIC KEY BLOCK-----". > > The keys are retrieved, it's just that "--keyserver-options > verbose,debug" erroneously reports that there's no key. While I believe you are seeing this, I'm not, and you're reporting a bug (keyserver fetches not working at all) that I daresay would have been noticed a long time ago. So, is your setup unusual in any way? Are you going through a proxy? What platform are you running on? Which (exact) version of the GPG code are you running? Does it happen when building with curl (yes, I understand you saw it when verifying a bug that only applies to curl-shim). Does it work when you don't apply the shutdown patch? David From gnupg-devel at spodhuis.org Sat Mar 2 08:41:51 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sat, 2 Mar 2013 02:41:51 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> Message-ID: <20130302074150.GA26755@redoubt.spodhuis.org> On 2013-03-01 at 20:19 -0500, David Shaw wrote: > So, is your setup unusual in any way? Are you going through a proxy? > What platform are you running on? Which (exact) version of the GPG > code are you running? Does it happen when building with curl (yes, I > understand you saw it when verifying a bug that only applies to > curl-shim). Does it work when you don't apply the shutdown patch? I edited this information out of my reply and only just realised, sorry. The issue is observed in GnuPG 2.0.19 with curl-shim, without the shutdown patch. If I remove the shutdown from common/http.c then the problem disappears. Because the core issue is truncated results, I should have been clearer about how this isn't so much version-specific in GnuPG. Still, since connections can still be reset for other reasons, albeit normally not so repeateably, more strident error reporting for truncated results might help keep users from assuming they got the key after all. If we can get a big WARNING: results truncated, likely missing signatures in the output from GnuPG, whenever the final armor line is missing, it'll be much clearer than "no keys found, but oh we imported key data anyway". -Phil From gnupg-devel at spodhuis.org Sat Mar 2 08:14:45 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sat, 2 Mar 2013 02:14:45 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> Message-ID: <20130302071444.GA25904@redoubt.spodhuis.org> On 2013-03-01 at 20:19 -0500, David Shaw wrote: > While I believe you are seeing this, I'm not, and you're reporting a > bug (keyserver fetches not working at all) that I daresay would have > been noticed a long time ago. No, keyserver fetches appeared to work, but with a spurious complaint that they don't work. In fact, it's worse. Tracked it down: the existing problem with the shutdowns? It can result in nginx dropping a connection part-way through, returning truncated results. So in the cases where it does error, GnuPG sees no final armor line, and complains about the _no_ data, then appears to import successfully anyway, when what it's actually getting is _incomplete_ data, a key with some of its signatures. So the user sees the import happen anyway and assumes they got a complete key. :( To see this, it needs to be a keyserver with an nginx proxy which has not yet rebuilt/reconfigured to avoid treating the write shutdown as a connection abort, you must have curl-shim in use, and you must be just the right network distance from the keyserver that you _usually_ succeed in connecting and getting data back, but the abort is processed while the connection is still returning data. For me, that's the distance between sks.spodhuis.org and keys2.kfwebs.net, especially when connecting over IPv6. It's still the nginx component in play, because this doesn't happen without the shutdown(sock, SHUT_WR). Do you think it's worth GnuPG detecting that it got truncated results by the missing final armor line and handling that with an explicit warning that it only got part of the keydata and signatures might be missing? In zsh: function keycheck { local server="$1" key="${2:-310D6001650E06D3}"; { print -l 'COMMAND GET' "HOST $server" 'PORT 11371' 'SCHEME hkp' '' $key | \ /usr/local/libexec/gpg2keys_hkp 2>&1 1>&3 | sed 's/^/STDERR: /' } 3>&1 1>&2 } % keycheck keys2.kfwebs.net | wc -l STDERR: * HTTP host:port post-SRV is "keys2.kfwebs.net:11371" STDERR: gpgkeys: key 310D6001650E06D3 not found on keyserver 169 % keycheck 84.215.15.221 | wc -l STDERR: * HTTP host:port post-SRV is "84.215.15.221:11371" STDERR: gpgkeys: key 310D6001650E06D3 not found on keyserver 222 % keycheck '[2001:16d8:ee3d:ee30:215:5dff:fe00:120d]' | wc -l STDERR: * HTTP host:port post-SRV is "2001:16d8:ee3d:ee30:215:5dff:fe00:120d:11371" STDERR: gpgkeys: key 310D6001650E06D3 not found on keyserver 169 % keycheck sks.spodhuis.org | wc -l STDERR: * HTTP host:port post-SRV is "sks.spodhuis.org:11371" 228 % keycheck localhost | wc -l STDERR: * HTTP host:port post-SRV is "localhost:11371" 228 Loose guess: Kristian has IPv6 via a tunnel, things get slightly slow while waiting for path MTU discovery to handle fragmentation, and so I get 169 lines of output, or 222 over IPv4, still truncated. (Those numbers are fairly repeatable for me, occasional variances.) Last few lines are: ----------------------------8< cut here >8------------------------------ rmMtbTaeuJu3lp+Or2OIcDGai8oal2GZf0cUjBg8tgXJ2/x1aVKwj8eQTKy3BRwxS9ZG/v2H kgB57OhUzC8Wne+PsdbPlbHB7Iwdq8e7Rc9BI3QyPcsSSWDM2bsvoe4DFp5XS5z2HP8eEBXp Znf9TXa+I3+WTK4Au7HTKfYqNXShP5nqlC1n8QacZdunpVbGaJRQV7T3fH9NSdxVGuo/ZWzV G2ur5R5PU2unozXCd4RyJ2r1OJwPiHFagp+nRXjR+KkhDC4oQLqODuUawHb2p70tMagCdc8e SI31niWrRDjZqWLQNt31nrHHUZuCE05ObEos12XfRIq97DHx75LvGtmT1uuPnHyJYwfDXhhE 69DI70zvh0fXV1AV2IaH7QZPygZ/Q0KWQTeeoF5o =E9CG -----END PGP PUBLIC KEY BLOCK----- ----------------------------8< cut here >8------------------------------ Over IPv4, get as far as: ----------------------------8< cut here >8------------------------------ rmMtbTaeuJu3lp+Or2OIcDGai8oal2GZf0cUjBg8tgXJ2/x1aVKwj8eQTKy3BRwxS9ZG/v2H STDERR: gpgkeys: key 310D6001650E06D3 not found on keyserver kgB57OhUzC8Wne+PsdbPlbHB7 KEY 0x310D6001650E06D3 FAILED 6 ----------------------------8< cut here >8------------------------------ and that "PlbHB7" is at the end of a packet, per tcpdump. ----------------------------8< cut here >8------------------------------ 0x05c0: 3248 0a6b 6742 3537 4f68 557a 4338 576e 2H.kgB57OhUzC8Wn 0x05d0: 652b 5073 6462 506c 6248 4237 e+PsdbPlbHB7 02:10:23.566187 IP (tos 0x0, ttl 64, id 47894, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->cc64)!) 94.142.240.6.55095 > 84.215.15.221.11371: ., cksum 0xc322 (correct), 144:144(0) ack 15929 win 8145 0x0000: 4500 0034 bb16 4000 4006 0000 5e8e f006 E..4.. at .@...^... 0x0010: 54d7 0fdd d737 2c6b 8b4b e740 742b bbc2 T....7,k.K. at t+.. 0x0020: 8010 1fd1 c322 0000 0101 080a 524a 3894 ....."......RJ8. 0x0030: 09b6 a5ce .... 02:10:23.566190 IP (tos 0x0, ttl 54, id 55379, offset 0, flags [DF], proto TCP (6), length 52) 84.215.15.221.11371 > 94.142.240.6.55095: F, cksum 0xe2cf (correct), 15929:15929(0) ack 144 win 114 0x0000: 4500 0034 d853 4000 3606 b927 54d7 0fdd E..4.S at .6..'T... 0x0010: 5e8e f006 2c6b d737 742b bbc2 8b4b e740 ^...,k.7t+...K.@ 0x0020: 8011 0072 e2cf 0000 0101 080a 09b6 a5d1 ...r............ 0x0030: 524a 3842 RJ8B 02:10:23.566204 IP (tos 0x0, ttl 64, id 47895, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->cc63)!) 94.142.240.6.55095 > 84.215.15.221.11371: ., cksum 0xc31f (correct), 144:144(0) ack 15930 win 8144 0x0000: 4500 0034 bb17 4000 4006 0000 5e8e f006 E..4.. at .@...^... 0x0010: 54d7 0fdd d737 2c6b 8b4b e740 742b bbc3 T....7,k.K. at t+.. 0x0020: 8010 1fd0 c31f 0000 0101 080a 524a 3894 ............RJ8. 0x0030: 09b6 a5d1 .... ----------------------------8< cut here >8------------------------------ (Ignore the bad cksum, that applies always to outbound frames, they're captured by BPF before the checksum is calculated) -Phil From gniibe at fsij.org Sat Mar 2 10:12:09 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 02 Mar 2013 18:12:09 +0900 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <5130FB3A.7060307@brainhub.org> References: <1362118942.6222.1.camel@cfw2.gniibe.org> <5130FB3A.7060307@brainhub.org> Message-ID: <1362215529.2962.1.camel@cfw2.gniibe.org> On 2013-03-01 at 11:02 -0800, Andrey Jivsov wrote: > Please consider using the compact representation of an ECC point: > http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card. Thank you very much. I didn't know this document. All that I had known about compression was x + (1-bit of y). It is good this will be mentioned in the update of RFC6090. > ( I will say that it's unfortunate that RFC 6637 was specified to use > SEC format 04 | x | y. The reason is that at the time I didn't know > about all the benefits that a *single* format such as > http://tools.ietf.org/html/draft-jivsov-ecc-compact would bring. I plan > to remedy this with another draft. So, it's a heads up. Please consider > not using the SEC format. ) I'm not sure about existing smartcard implementations and their ECDSA features. Possibly, they already took the approach of uncompressed format. If it is easier for them to use the uncompressed format, I think that it would make sense for OpenPGP card specification to allow this SEC format. Sure, I will use this compression format for Gnuk. Key generation for ECDSA has not yet implemented there. -- From achim at pietig.com Sat Mar 2 14:30:22 2013 From: achim at pietig.com (Achim Pietig) Date: Sat, 02 Mar 2013 14:30:22 +0100 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <5130FB3A.7060307@brainhub.org> References: <1362118942.6222.1.camel@cfw2.gniibe.org> <5130FB3A.7060307@brainhub.org> Message-ID: <5131FEEE.9080206@pietig.com> Hi, actual all relevant ECDSA standards follow the BSI specification "Technical Guideline TR-03110-1 - Advanced Security Mechanisms for Machine Readable Travel Documents". In addition BSI launched "Technical Guideline TR-03111 - Elliptic Curve Cryptography" as basis for codings etc. The following standards/inplementations aggreed to follow: EN 14890: Application Interface for smart cards used as Secure Signature Creation Devices CEN 15480: Identification card systems - European Citizen Card German Electronic Health Card (eGK) Gen2 ISO 7816-8 in the next version (in progress, I'm member of the national body of the standardisation committee and will get information early). All relevant ECDSA implementation on smart cards will follow this in the nearest future, so the OpenPGP card should do also. BSI defines the following for PubKeys: The conversion of Elliptic Curve Points to octet strings is specified in [3]. The uncompressed format SHALL be used. The data objects contained in an EC public key are shown in Table 27. The order of the data objects is fixed, CONDITIONAL domain parameters MUST be either all present, except the cofactor, or all absent as follows: Data Object Abbrev. Tag Type Certificate Object Identifier 0x06 Object Identifier m (mandatory) Prime modulus p 0x81 Unsigned Integer c (conditional) First coefficient a 0x82 Unsigned Integer c Second coefficient b 0x83 Unsigned Integer c Base point G 0x84 Elliptic Curve Point c Order of the base point r 0x85 Unsigned Integer c Public point Y 0x86 Elliptic Curve Point m Cofactor f 0x87 Unsigned Integer c German eGK (e. g.) uses Tag 06 and 86 only, I prefere this for the Open PGP card also. The coding of Tag 86 is as follows: In uncompressed encoding the point P is represented by two eld elements, its x-coordinate denoted by xP and its y-coordinate denoted by yP. If b is the bit length of p, storing (xP ; yP ) requires 2b bits (excluding additional data required for the encoding). The uncompressed encoding PU is de fined as PU = C || X || Y , where C = 0x04 X = FE2OS(xP ) Y = FE2OS(yP ) All this relates to Niibes proposal and I see no way to change it, if the card will be in compliance with standards. The response of GENERATE ASYMMETRIC KEY PAIR will be: 7F49 xx 06 xx OID 86 xx Elliptic Curve Point For key import we have to check if this information is enough or if we should use additional parameters (see conditional information in BSI table). Best regards, Achim Am 01.03.2013 20:02, schrieb Andrey Jivsov: > Hi NIIBE. > > Please consider using the compact representation of an ECC point: http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card. > > I plan to submit a relevant proposal to use the compact representation in OpenPGP. > > The benefit of the compact representation is that you will have to transmit less than half of bytes of the point over in the host-to-card protocol. > > For this compact representation of the ECC point to work one needs to slightly adjust the key generation. It's always possible to do so with the proposed method, even with any existing method that > generates keys on the card (one uses "black box" approach in this case). > > The ideal scenario is when the key generation is already generating compliant keys. Thus, I suggest to change the key generation on the card to always return the compliant keys. > > IMO we should all generate compliant OpenPGP keys in the entire OpenPGP ecosystem (and beyond as well, as keys are sometimes migrated between PKI and OpenPGP). Well, at least compliant keys are within > our reach at OpenPGP. > > ( I will say that it's unfortunate that RFC 6637 was specified to use SEC format 04 | x | y. The reason is that at the time I didn't know about all the benefits that a *single* format such as > http://tools.ietf.org/html/draft-jivsov-ecc-compact would bring. I plan to remedy this with another draft. So, it's a heads up. Please consider not using the SEC format. ) > > Thank you. > > On 02/28/2013 10:22 PM, NIIBE Yutaka wrote: >> Hello, >> >> This message is CC-ed to GnuPG-Devel List. >> >> I am currently extending GnuPG so that it will support OpenPGP card >> with ECDSA feature in future. >> >> So far, following two things are modifications to the current OpenPGP >> card specification. >> >> Could you please give me comments? >> >> >> (1) 4.3.3.6 Algorithm Attributes >> >> ECDSA: >> >> Byte Length Value >> 01 01 Algorithm ID (RFC6637) 13 = ECDSA >> 02- Variable OID (RFC6637) >> 2A 86 48 CE 3D 03 01 07 NIST curve P-256 >> 2B 81 04 00 22 NIST curve P-384 >> 2B 81 04 00 23 NIST curve P-521 >> >> I think that use of OID here would be best, since OID is used to >> identify the curve in OpenPGP ECC (RFC 6637). >> >> >> (2) 7.2.11 GENERATE ASYMMETRIC KEY PAIR >> >> Set of public key data objects for ECDSA >> >> 81 xx Public key >> >> In the format of uncompressed point: >> >> 04 || x || y >> >> where x and y are coordinate of the point P = (x, y). >> Big-endian, zero-padded. >> (c.f. Section 6. Conversion Primitives in RFC 6637) >> >> I think that curve specification (For example, Generator, Order, etc.) >> is defined by OID in the Algorithm Attributes, it's enough to return >> the public key, EC point, and it's natural to use standard encoding >> of uncompressed point. >> > > From achim at pietig.com Sat Mar 2 15:35:11 2013 From: achim at pietig.com (Achim Pietig) Date: Sat, 02 Mar 2013 15:35:11 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1358217413.2667.6.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <50EE75B5.3090009@pietig.com> <1358217413.2667.6.camel@cfw2.gniibe.org> Message-ID: <51320E1F.8030009@pietig.com> Hi, I was asked for the latest standards relevant for PIN or password input with PINPads: PC/SC V2: Interoperability Specification for ICCs and Personal Computer Systems, Part 10 IFDs with Secure PIN Entry Capabilities, Revision 2.02.09 November 2012 Secoder 2: from german banks (GeldKarte), not public available Most standards support the PIN 2 block format as most (banking standard for digits only). The OpenPGP card uses alphanumeric password, a reason was to use passphrases on the card too. If the support of readers for alpha passwords with variable length is too complex, a next version of the OpenPGP card may support PIN 2-block too, but then an algorithm ID or a usage flag in Extended capabilies is needed. What do you think? Regards, Achim Am 15.01.2013 03:36, schrieb NIIBE Yutaka: > Thanks for your comments. > > My replies are by different order. > > On 2013-01-10 at 09:03 +0100, Achim Pietig wrote: >> "pinpad" is the most common word in standards. > > I see. > >> If support for "old" readers with fixed length input is requirerd, I >> prefere a local var (e. g. gpgconf) with the fixed length preferred >> by the user. If the var is 0 or not defined, the min-max length >> should be taken from the card. The var may be evaluated by pinentry. >> If the password is defined by a keyboard, --disable-pinpad may be >> useful. All this affects the local environment only. > > I understand the need for configuration on host PC (for card specific > configuration). The issue is: how to implement this. IIUC, SCDaemon > is the lower level driver which handles smartcard/token communication > (perhaps, this understanding of mine would be wrong), and how to get > card specific information is under discussion. > >> Actual there are 3 standards for readers with PIN-pad, all support >> var-lenth-pins, so older readers will be obsolet soon. If you want >> to support this old items anyway, then keep it simple... It makes >> no sence to me to find a solution with new information in card or >> servers etc. to make this run at any pin-pad - standard compliant >> pinpads will run with min-max values! > > Could you please let me know the references for the standards? A > vendor which I contacted last year claimed that the reader is standard > compliant (even if it doesn't support variable length input). > > Well, I understand that fixed length input support should be special > case. > > To summarize discussion, I'd like to propose the following for pinpad > input. > > * Default is variable length pinpad input when reader supports the > feature. > > * Use pinentry by keyboard on host PC, when reader doesn't supports > the feature (including reader supports pinpad input but requires > fixed length input). > > * Only when a user wants to do special thing, he needs to specify > this. Special cases are: > > (1) Use pinentry by keyboard even with pinpad reader. > (for cases when PIN has characters other than digits.) > > (2) Use fixed length input. > >> Login-Data is an ISO definied data object (7816-6). >> It should not contain other information than defined by ISO, so >> first check if this information is possible there. > > It says: > > Proprietary login data > > Referenced by tag '5E', this interindustry data element > consists of login data with proprietary structures not > specified in ISO/IEC 7816. > From dshaw at jabberwocky.com Sat Mar 2 17:27:14 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 2 Mar 2013 11:27:14 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130302071444.GA25904@redoubt.spodhuis.org> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> Message-ID: On Mar 2, 2013, at 2:14 AM, Phil Pennock wrote: > To see this, it needs to be a keyserver with an nginx proxy which has > not yet rebuilt/reconfigured to avoid treating the write shutdown as a > connection abort, you must have curl-shim in use, and you must be just > the right network distance from the keyserver that you _usually_ succeed > in connecting and getting data back, but the abort is processed while > the connection is still returning data. > > For me, that's the distance between sks.spodhuis.org and > keys2.kfwebs.net, especially when connecting over IPv6. > > It's still the nginx component in play, because this doesn't happen > without the shutdown(sock, SHUT_WR). > > Do you think it's worth GnuPG detecting that it got truncated results by > the missing final armor line and handling that with an explicit warning > that it only got part of the keydata and signatures might be missing? I think this is sufficiently obscure (an old version of GPG2 that still has the shutdown() code, built with curl-shim, talking to a keyserver that is behind a nginx proxy, which has to have a particular configuration) that it is not worth putting in a special case for. Change any of the above requirements and it no longer happens. Especially since GPG2 will now come without the shutdown() code anyway, I don't see any benefit in special-casing this. Note it's also not a case of just signatures missing. It's part of the *key* that's missing. If things were cut off in the midst of the signature block, then that implies you're missing the subkeys as well. Worse, say things were cut off so that you got a subkey, its binding signature, but then the revocation for that subkey was cut off. As I see it, the real problem here is that there are only two cases in the keyserver code: got a key, and didn't get a key. "Didn't get a key" is reported to the user as "key not found" due to the old pks server which returned HTTP 200 even for key not found, so there was no reliable way to tell the difference between failure and not-found. I vaguely recall that someone was enhancing sks so that it returned a proper 404 for key-not-found. If that has happened, then I can can add code to GPG to have the proper three states: got a key, failed to get a complete key (where you may be left with part of a key), and key not found. That should resolve the problem with informing the user. A quick check of a few sks servers show that keys2.kfwebs.net does properly return a 404 for an unknown key. pgp.mit.edu returns a 500, but this is also running an older version of sks, possibly before the 404 was added. David From beebe at math.utah.edu Sat Mar 2 17:37:20 2013 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 2 Mar 2013 09:37:20 -0700 (MST) Subject: gpgme-1.4.0 test hang Message-ID: I've made attempts to build gpgme-1.4.0 on more than two dozen flavors of Unix, with very limited success. On several systems, the build completes, and the check runs through several tests, then reaches this point and hangs: PASS: t-keylist -----BEGIN ENCRYPTED MESSAGE----- MIAGCSqGSIb3DQEHA6CAMIACAQAxggELMIIBBwIBADBwMGsxCzAJBgNVBAYTAkRF MRMwEQYDVQQHFApE/HNzZWxkb3JmMRYwFAYDVQQKEw1nMTAgQ29kZSBHbWJIMRkw FwYDVQQLExBBZWd5cHRlbiBQcm9qZWN0MRQwEgYDVQQDEwt0ZXN0IGNlcnQgMQIB ADANBgkqhkiG9w0BAQEFAASBgJJX+RMsvtHhhW4LRx59p77nQqYdXLafb0zokxd2 zFFqQ00QT70Ej5x6zc0hpcGMgwHjFeyq9UwLYrx3FH5vCY2u/MzLXaNwL9VsfhJ+ gjFHgDVtiqT6/6GbpQWhqzU+cDPGCjebo4rpUaHdmlX3wMX/P6o7S3ck7/5r2T5k e/XGMIAGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIxj3oxbE4yEiggAQIHN/FW/9C jloECB8nx4cmpAxXAAAAAAAAAAAAAA== -----END ENCRYPTED MESSAGE----- PASS: t-encrypt Running the top utility in another window show that no CPU time is consumed. I then ran strace on the "make check" run to log system calls. The output log is not very illuminating: near the end, I get 31268 select(5, [4], [], NULL, {1, 0}) = 0 (Timeout) 31268 select(5, [4], [], NULL, {1, 0}) = 0 (Timeout) 31268 select(5, [4], [], NULL, {1, 0}) = 0 (Timeout) ... many times ... 31268 select(5, [4], [], NULL, {1, 0} 31293 <... select resumed> ) = ? ERESTARTNOHAND (To be restarted) 31291 <... recvmsg resumed> 0x7fff77d2ea18, 0) = ? ERESTARTSYS (To be restarted) 31268 <... select resumed> ) = ? ERESTARTNOHAND (To be restarted) The last few lines may correspond to my terminating the run by an external kill command. Does anyone else on this list see similar problems? ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From kristian.fiskerstrand at sumptuouscapital.com Sat Mar 2 22:12:25 2013 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 02 Mar 2013 22:12:25 +0100 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> Message-ID: <51326B39.8020904@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/02/2013 05:27 PM, David Shaw wrote: > On Mar 2, 2013, at 2:14 AM, Phil Pennock > wrote: > ... > > A quick check of a few sks servers show that keys2.kfwebs.net does > properly return a 404 for an unknown key. pgp.mit.edu returns a > 500, but this is also running an older version of sks, possibly > before the 404 was added. Indeed, as far as I can recall this behavior was implemented in 1.1.4, and is listed in the changelog as - - Improved the HTTP status and HTTP error codes returned for various situations and added checks for more error conditions. The only pool that guarantee 1.1.4 is subset.pool.sks-keyservers.net , the minimum requirement for main is 1.1.3. - -- - ---------------------------- Kristian Fiskerstrand Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Cogito ergo sum I think, therefore I am -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta163 (GNU/Linux) iQIcBAEBCAAGBQJRMms0AAoJEAt/i2Dj7frjvgUP/jXOOneTZrcPvYWMa5V35wO4 e+MdTrTCtGV4tIk52aW6e6yjUV3kw/r/O8QH1EKOB60okxuEHPfk/1UlTF3ihVP4 ZaxT23hV9sep9aKIFCVVL5y/TqvwFgxS7ZwC9Mvx16ZYxOK4JTkEN2UsSN13heJ0 Db0utT/4YD8HjCaMYDPhhHKzTVDi9wBWGa6GT/Pebw9no1SNwNsN5lNTkENDSdB/ w96ye/+c/WcrgQZhG3bgqyMcfVLjQR9qx7M8FEKKO2bHDwgTWJbdfHe9IdFbCwAC 2hka09x8egWS98IEYePDwePBGHW0+DCHyPcp605BN7ueCMBnIyM7Wd+xgu/yVJQa FU+AuDr7rhrTRR0HIDFtvcd3Gndayr7Paib/zoPeux3hlQ/iB3P9aoFjSJYB0L05 I9JgOR/zCPL9/W/95T4TMVa1CfN8wRH0orJGA1WOqBQpEYylA32L1JpIlLQRgKyB 1PiTovzdmV9DBnsIZ6EJwDdjZWH0a9jT+ZlOMkxm98b/7GPDp06fWO28RaibizW7 6zk3s6Z0DhlbswWYEz7UQQboSFA73fTZ+KxJHI08MIMprrxedAWuGVlIgiDOqwkh 5NGRNL4o9/BoDe8zCoR/4ym2hTrb+YoLfCn45oBkBCwgEAC1Vz0juXweVJs9tDRm cTGrMNqA4lS1NjbE8n2c =9VVC -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Mar 3 02:38:49 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 2 Mar 2013 20:38:49 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <51326B39.8020904@sumptuouscapital.com> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> <51326B39.8020904@sumptuouscapital.com> Message-ID: <5B287E05-5A68-441B-B2CD-94DC54481263@jabberwocky.com> On Mar 2, 2013, at 4:12 PM, Kristian Fiskerstrand wrote: >> A quick check of a few sks servers show that keys2.kfwebs.net does >> properly return a 404 for an unknown key. pgp.mit.edu returns a >> 500, but this is also running an older version of sks, possibly >> before the 404 was added. > > Indeed, as far as I can recall this behavior was implemented in 1.1.4, > and is listed in the changelog as > - - Improved the HTTP status and HTTP error codes returned for various > situations and added checks for more error conditions. > > The only pool that guarantee 1.1.4 is subset.pool.sks-keyservers.net , > the minimum requirement for main is 1.1.3. Ok, this is reasonable. I'll add some code to gpgkeys to look for the HTTP status. It'll only really work properly on sks 1.1.4 or later, but it'll work well enough on earlier versions (it'll say "key can't be retrieved" rather than "key not found" if the key isn't found). That addresses all 4 cases here, since gpgkeys can use those status codes, along with the state it already has, to tell the difference between key found (either complete or incomplete), not found, and server failed. David From gnupg-devel at spodhuis.org Sun Mar 3 02:30:11 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sat, 2 Mar 2013 20:30:11 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> Message-ID: <20130303013011.GA36377@redoubt.spodhuis.org> On 2013-03-02 at 11:27 -0500, David Shaw wrote: > I think this is sufficiently obscure (an old version of GPG2 that still has the shutdown() code, built with curl-shim, talking to a keyserver that is behind a nginx proxy, which has to have a particular configuration) that it is not worth putting in a special case for. Change any of the above requirements and it no longer happens. Especially since GPG2 will now come without the shutdown() code anyway, I don't see any benefit in special-casing this. The point I've failed to be clear about is that the behaviour of GnuPG here is the same whenever a transfer is interrupted. The only thing special right now is we have a way of reproducibly forcing a transfer interruption. The changes will mean that we'll no longer be able to reproducibly force a transfer interruption. The behaviour of GnuPG when it encounters an interrupted transfer will remain the same. > Note it's also not a case of just signatures missing. It's part of the *key* that's missing. If things were cut off in the midst of the signature block, then that implies you're missing the subkeys as well. Worse, say things were cut off so that you got a subkey, its binding signature, but then the revocation for that subkey was cut off. Yes. That's why I think it's bad and worth having better diagnostics. > As I see it, the real problem here is that there are only two cases in the keyserver code: got a key, and didn't get a key. "Didn't get a key" is reported to the user as "key not found" due to the old pks server which returned HTTP 200 even for key not found, so there was no reliable way to tell the difference between failure and not-found. I vaguely recall that someone was enhancing sks so that it returned a proper 404 for key-not-found. If that has happened, then I can can add code to GPG to have the proper three states: got a key, failed to get a complete key (where you may be left with part of a key), and key not found. That should resolve the problem with informing the user. > > A quick check of a few sks servers show that keys2.kfwebs.net does properly return a 404 for an unknown key. pgp.mit.edu returns a 500, but this is also running an older version of sks, possibly before the 404 was added. You're welcome. :) I added the improved HTTP error code logic, basically because I saw incorrect codes and thought it needed fixing. I was not aware that this had been causing operational issues and work-arounds. Are there any other behaviours of SKS that are currently causing GnuPG issues? We can try to get those fixed. For backwards compatibility, surely the three states can be told apart by: missing: Did not get a "-----BEGIN PGP PUBLIC KEY BLOCK-----" line incomplete: Got that line, but did not get a "-----END PGP PUBLIC KEY BLOCK-----" line found: Got both lines -Phil From dshaw at jabberwocky.com Sun Mar 3 03:54:54 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 2 Mar 2013 21:54:54 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130303013011.GA36377@redoubt.spodhuis.org> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> <20130303013011.GA36377@redoubt.spodhuis.org> Message-ID: On Mar 2, 2013, at 8:30 PM, Phil Pennock wrote: > I added the improved HTTP error code logic, basically because I saw > incorrect codes and thought it needed fixing. I was not aware that this > had been causing operational issues and work-arounds. > > Are there any other behaviours of SKS that are currently causing GnuPG > issues? We can try to get those fixed. Ha, it's an interesting question. It's been a number of years since the keyserver code was written (before sks was written). A few decisions were made based on the fact that pks was not actively maintained and so was effectively unchangeable, but yet was the defacto keyserver. Thanks for the offer. I'll see if anything else jumps out. > For backwards compatibility, surely the three states can be told apart > by: > missing: Did not get a "-----BEGIN PGP PUBLIC KEY BLOCK-----" line > incomplete: Got that line, but did not get a > "-----END PGP PUBLIC KEY BLOCK-----" line > found: Got both lines Yes, this is more or less what the code does. David From JPClizbe at gingerbear.net Sun Mar 3 04:38:02 2013 From: JPClizbe at gingerbear.net (John Clizbe) Date: Sat, 02 Mar 2013 21:38:02 -0600 Subject: lber link error in gnupg-2.1.0beta3/dirmngr Message-ID: <5132C59A.9000307@GingerBear.net> Slackware 14.0 OpenLDAP 2.4.31 Get a link error undefined reference to symbol 'ber_free' in dirmngr with advisory message "note: 'ber_free' is defined in DSO /usr/lib/liblber-2.4.so.2 so try adding it to the linker command line" Adding -llber to the LDAPLIBS value in dirmngr/Makefile fixes the problem, but it'd probably be better if configure handled it. Making all in dirmngr make[2]: Entering directory `/tmp/gnupg-2.1.0beta3/dirmngr' make all-am make[3]: Entering directory `/tmp/gnupg-2.1.0beta3/dirmngr' gcc -I/usr/include -O2 -march=i486 -mtune=i686 -Wall -Wno-pointer-sign -Wpointer-arith -o dirmngr-client dirmngr-client.o ../common/libcommon.a no-libgcrypt.o ../gl/libgnu.a -lassuan -lgpg-error -lgpg-error gcc -O2 -march=i486 -mtune=i686 -Wall -Wno-pointer-sign -Wpointer-arith -o dirmngr_ldap dirmngr_ldap-dirmngr_ldap.o ../common/libcommon.a no-libgcrypt.o ../gl/libgnu.a -lresolv -lgpg-error -lldap /usr/lib/gcc/i486-slackware-linux/4.7.2/../../../../i486-slackware-linux/bin/ld: dirmngr_ldap-dirmngr_ldap.o: undefined reference to symbol 'ber_free' /usr/lib/gcc/i486-slackware-linux/4.7.2/../../../../i486-slackware-linux/bin/ld: note: 'ber_free' is defined in DSO /usr/lib/liblber-2.4.so.2 so try adding it to the linker command line /usr/lib/liblber-2.4.so.2: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[3]: *** [dirmngr_ldap] Error 1 make[3]: Leaving directory `/tmp/gnupg-2.1.0beta3/dirmngr' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/gnupg-2.1.0beta3/dirmngr' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnupg-2.1.0beta3' make: *** [all] Error 2 -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" From openpgp at brainhub.org Sun Mar 3 05:41:20 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Sat, 02 Mar 2013 20:41:20 -0800 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <5131FEEE.9080206@pietig.com> References: <1362118942.6222.1.camel@cfw2.gniibe.org> <5130FB3A.7060307@brainhub.org> <5131FEEE.9080206@pietig.com> Message-ID: <5132D470.6090304@brainhub.org> Hello Achim. If you are you implementing the key generation on the card, please consider generating "compliant" keys. There are the keys that allow efficient compression. If you cannot use compression in some part of communication, that's up to you. However, this will allow efficient representation of any such a key in a compressed form (for anybody for whom it's an option). As proven in the spec, no security is lost by doing so. Thank you. On 03/02/2013 05:30 AM, Achim Pietig wrote: > Hi, > > actual all relevant ECDSA standards follow the BSI specification "Technical Guideline TR-03110-1 - Advanced Security Mechanisms for Machine Readable Travel Documents". > In addition BSI launched "Technical Guideline TR-03111 - Elliptic Curve Cryptography" as basis for codings etc. > > The following standards/inplementations aggreed to follow: > EN 14890: Application Interface for smart cards used as Secure Signature Creation Devices > CEN 15480: Identification card systems - European Citizen Card > German Electronic Health Card (eGK) Gen2 > ISO 7816-8 in the next version (in progress, I'm member of the national body of the standardisation committee and will get information early). > > All relevant ECDSA implementation on smart cards will follow this in the nearest future, so the OpenPGP card should do also. > > BSI defines the following for PubKeys: > > The conversion of Elliptic Curve Points to octet strings is specified in [3]. The uncompressed format SHALL be used. > > The data objects contained in an EC public key are shown in Table 27. The order of the data objects is fixed, CONDITIONAL domain parameters MUST be either all present, except the cofactor, or all > absent as follows: > > Data Object Abbrev. Tag Type Certificate > Object Identifier 0x06 Object Identifier m (mandatory) > Prime modulus p 0x81 Unsigned Integer c (conditional) > First coefficient a 0x82 Unsigned Integer c > Second coefficient b 0x83 Unsigned Integer c > Base point G 0x84 Elliptic Curve Point c > Order of the base point r 0x85 Unsigned Integer c > Public point Y 0x86 Elliptic Curve Point m > Cofactor f 0x87 Unsigned Integer c > > German eGK (e. g.) uses Tag 06 and 86 only, I prefere this for the Open PGP card also. > > The coding of Tag 86 is as follows: > In uncompressed encoding the point P is represented by two eld elements, its x-coordinate denoted by xP and its y-coordinate denoted by yP. > If b is the bit length of p, storing (xP ; yP ) requires 2b bits (excluding additional data required for the encoding). > The uncompressed encoding PU is de fined as PU = C || X || Y , where > C = 0x04 > X = FE2OS(xP ) > Y = FE2OS(yP ) > > All this relates to Niibes proposal and I see no way to change it, if the card will be in compliance with standards. > > The response of GENERATE ASYMMETRIC KEY PAIR will be: > 7F49 xx > 06 xx OID > 86 xx Elliptic Curve Point > > For key import we have to check if this information is enough or if we should use additional parameters (see conditional information in BSI table). > > Best regards, > Achim > > > > Am 01.03.2013 20:02, schrieb Andrey Jivsov: >> Hi NIIBE. >> >> Please consider using the compact representation of an ECC point: http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card. >> >> I plan to submit a relevant proposal to use the compact representation in OpenPGP. >> >> The benefit of the compact representation is that you will have to transmit less than half of bytes of the point over in the host-to-card protocol. >> >> For this compact representation of the ECC point to work one needs to slightly adjust the key generation. It's always possible to do so with the proposed method, even with any existing method that >> generates keys on the card (one uses "black box" approach in this case). >> >> The ideal scenario is when the key generation is already generating compliant keys. Thus, I suggest to change the key generation on the card to always return the compliant keys. >> >> IMO we should all generate compliant OpenPGP keys in the entire OpenPGP ecosystem (and beyond as well, as keys are sometimes migrated between PKI and OpenPGP). Well, at least compliant keys are within >> our reach at OpenPGP. >> >> ( I will say that it's unfortunate that RFC 6637 was specified to use SEC format 04 | x | y. The reason is that at the time I didn't know about all the benefits that a *single* format such as >> http://tools.ietf.org/html/draft-jivsov-ecc-compact would bring. I plan to remedy this with another draft. So, it's a heads up. Please consider not using the SEC format. ) >> >> Thank you. >> >> On 02/28/2013 10:22 PM, NIIBE Yutaka wrote: >>> Hello, >>> >>> This message is CC-ed to GnuPG-Devel List. >>> >>> I am currently extending GnuPG so that it will support OpenPGP card >>> with ECDSA feature in future. >>> >>> So far, following two things are modifications to the current OpenPGP >>> card specification. >>> >>> Could you please give me comments? >>> >>> >>> (1) 4.3.3.6 Algorithm Attributes >>> >>> ECDSA: >>> >>> Byte Length Value >>> 01 01 Algorithm ID (RFC6637) 13 = ECDSA >>> 02- Variable OID (RFC6637) >>> 2A 86 48 CE 3D 03 01 07 NIST curve P-256 >>> 2B 81 04 00 22 NIST curve P-384 >>> 2B 81 04 00 23 NIST curve P-521 >>> >>> I think that use of OID here would be best, since OID is used to >>> identify the curve in OpenPGP ECC (RFC 6637). >>> >>> >>> (2) 7.2.11 GENERATE ASYMMETRIC KEY PAIR >>> >>> Set of public key data objects for ECDSA >>> >>> 81 xx Public key >>> >>> In the format of uncompressed point: >>> >>> 04 || x || y >>> >>> where x and y are coordinate of the point P = (x, y). >>> Big-endian, zero-padded. >>> (c.f. Section 6. Conversion Primitives in RFC 6637) >>> >>> I think that curve specification (For example, Generator, Order, etc.) >>> is defined by OID in the Algorithm Attributes, it's enough to return >>> the public key, EC point, and it's natural to use standard encoding >>> of uncompressed point. >>> >> >> From wk at gnupg.org Sun Mar 3 17:15:14 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 03 Mar 2013 17:15:14 +0100 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <1362076981.20807.1.camel@fermat.scientia.net> (Christoph Anton Mitterer's message of "Thu, 28 Feb 2013 19:43:01 +0100") References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <1362076981.20807.1.camel@fermat.scientia.net> Message-ID: <87txoswjcd.fsf@vigenere.g10code.de> On Thu, 28 Feb 2013 19:43, calestyo at scientia.net said: > I wonder how many important stuff makes it in only one of the two > branches... Well, SKS should have been bug/feature compatible to PKS ;-). Shutting down the sending side is a pretty standard pattern for a TCP service. But well, these days the Internet virtually runs on HTTP 1.0 only. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Mar 3 17:23:46 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 03 Mar 2013 17:23:46 +0100 Subject: gpgme-1.4.0 test hang In-Reply-To: (Nelson H. F. Beebe's message of "Sat, 2 Mar 2013 09:37:20 -0700 (MST)") References: Message-ID: <87ppzgwiy5.fsf@vigenere.g10code.de> On Sat, 2 Mar 2013 17:37, beebe at math.utah.edu said: > PASS: t-encrypt > > Running the top utility in another window show that no CPU time is > consumed. I then ran strace on the "make check" run to log system The next test after t-encrypt is t-verify - this is the test which hangs. I assume that this is a GPGSM based tests. We need to check close what's going wrong here. X.509 testing is often a bit fragile. I'll check tomorrow. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lists-gnupgdev at lina.inka.de Sun Mar 3 21:54:31 2013 From: lists-gnupgdev at lina.inka.de (Bernd Eckenfels) Date: Sun, 03 Mar 2013 21:54:31 +0100 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <5B287E05-5A68-441B-B2CD-94DC54481263@jabberwocky.com> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> <51326B39.8020904@sumptuouscapital.com> <5B287E05-5A68-441B-B2CD-94DC54481263@jabberwocky.com> Message-ID: Am 03.03.2013, 02:38 Uhr, schrieb David Shaw : > Ok, this is reasonable. I'll add some code to gpgkeys to look for the > HTTP status. It'll only really work properly on sks 1.1.4 or later, but > it'll work well enough on earlier versions (it'll say "key can't be > retrieved" rather than "key not found" if the key isn't found). That > addresses all 4 cases here, since gpgkeys can use those status codes, > along with the state it already has, to tell the difference between key > found (either complete or incomplete), not found, and server failed. For an aorted transfer, it is required to check for Content-Length or Chunk borders. I dont see how the status code would/could help. Since an aborted transfer still has a status of 200. Gruss Bernd -- http://bernd.eckenfels.net From dshaw at jabberwocky.com Mon Mar 4 00:18:24 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 3 Mar 2013 18:18:24 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> <20130301222424.GA16681@redoubt.spodhuis.org> <1AA2C1C9-BCF6-4EC4-9897-5E5DEA2DBEC3@jabberwocky.com> <20130301235603.GA18897@redoubt.spodhuis.org> <20130302071444.GA25904@redoubt.spodhuis.org> <51326B39.8020904@sumptuouscapital.com> <5B287E05-5A68-441B-B2CD-94DC54481263@jabberwocky.com> Message-ID: <5F79CF28-C460-4F42-AE10-AE7368CFDC36@jabberwocky.com> On Mar 3, 2013, at 3:54 PM, "Bernd Eckenfels" wrote: > Am 03.03.2013, 02:38 Uhr, schrieb David Shaw : >> Ok, this is reasonable. I'll add some code to gpgkeys to look for the HTTP status. It'll only really work properly on sks 1.1.4 or later, but it'll work well enough on earlier versions (it'll say "key can't be retrieved" rather than "key not found" if the key isn't found). That addresses all 4 cases here, since gpgkeys can use those status codes, along with the state it already has, to tell the difference between key found (either complete or incomplete), not found, and server failed. > > For an aorted transfer, it is required to check for Content-Length or > Chunk borders. I dont see how the status code would/could help. Since an > aborted transfer still has a status of 200. Unfortunately, some SKSes out there do not provide Content-Length. That doesn't matter, as gpgkeys knows something about the object being fetched (i.e. it's a key). It currently tells the difference between the various cases as such: HTTP 200: if key has both BEGIN and END, success. If key has only BEGIN, incomplete. If key has neither BEGIN nor END, fail. HTTP 404: key not found. HTTP (anything else): fail. David From gniibe at fsij.org Mon Mar 4 02:19:00 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 04 Mar 2013 10:19:00 +0900 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <1362215529.2962.1.camel@cfw2.gniibe.org> References: <1362118942.6222.1.camel@cfw2.gniibe.org> <5130FB3A.7060307@brainhub.org> <1362215529.2962.1.camel@cfw2.gniibe.org> Message-ID: <1362359940.2678.2.camel@cfw2.gniibe.org> Hello Andrey, On 2013-03-02 at 18:12 +0900, NIIBE Yutaka wrote: > On 2013-03-01 at 11:02 -0800, Andrey Jivsov wrote: > > Please consider using the compact representation of an ECC point: > > http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card. > > Thank you very much. I didn't know this document. All that I had > known about compression was x + (1-bit of y). I considered again. For new keys, we will be able to take advantage of this compact representation. But, there are already ECDSA keys out there. I will limit key space for Gnuk for new keys, so that keys generated on Gnuk Token can be represented by the compact representation. But, note that most users of Gnuk use writekey command, generating keys on host PC. I think that Gnuk Token should not limit key space for writekey command (host PC -> Gnuk Token), but should accept keys of other half space for inter-operablity. Speaking for GnuPG, same argument could be applied. It is true that there has been no released versions which support ECDSA yet. But, it should handle any keys by any OpenPGP ECC implementations. Besides, GnuPG supports SSH and X.509. With the possibility of 50%, existing keys of ECDSA couldn't be represented by the compact representation. I think that GnuPG should handle both of the compact representation and the uncompressed representation. -- From gniibe at fsij.org Mon Mar 4 04:03:51 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 04 Mar 2013 12:03:51 +0900 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <5131FEEE.9080206@pietig.com> References: <1362118942.6222.1.camel@cfw2.gniibe.org> <5130FB3A.7060307@brainhub.org> <5131FEEE.9080206@pietig.com> Message-ID: <1362366231.2678.3.camel@cfw2.gniibe.org> Hello Achim, Thank you very much for your comments and references. On 2013-03-02 at 14:30 +0100, Achim Pietig wrote: > BSI defines the following for PubKeys: > > The conversion of Elliptic Curve Points to octet strings is > specified in [3]. The uncompressed format SHALL be used. [...] > Data Object Abbrev. Tag Type Certificate > Object Identifier 0x06 Object Identifier m (mandatory) > Prime modulus p 0x81 Unsigned Integer c (conditional) > First coefficient a 0x82 Unsigned Integer c > Second coefficient b 0x83 Unsigned Integer c > Base point G 0x84 Elliptic Curve Point c > Order of the base point r 0x85 Unsigned Integer c > Public point Y 0x86 Elliptic Curve Point m > Cofactor f 0x87 Unsigned Integer c Thank you for the reference. > German eGK (e. g.) uses Tag 06 and 86 only, I prefere this for the > Open PGP card also. I see. > The response of GENERATE ASYMMETRIC KEY PAIR will be: > 7F49 xx > 06 xx OID > 86 xx Elliptic Curve Point With this format, I will update my work of GnuPG experimental patch and Gnuk experimental implementation. > For key import we have to check if this information is enough or if > we should use additional parameters (see conditional information in > BSI table). I think that OID is enough and Public point is optional for key import. Private key data (scalar value) is needed. -- From gnupg-devel at spodhuis.org Mon Mar 4 09:13:12 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 4 Mar 2013 03:13:12 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <87txoswjcd.fsf@vigenere.g10code.de> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <1362076981.20807.1.camel@fermat.scientia.net> <87txoswjcd.fsf@vigenere.g10code.de> Message-ID: <20130304081312.GA65178@redoubt.spodhuis.org> On 2013-03-03 at 17:15 +0100, Werner Koch wrote: > On Thu, 28 Feb 2013 19:43, calestyo at scientia.net said: > > I wonder how many important stuff makes it in only one of the two > > branches... > > Well, SKS should have been bug/feature compatible to PKS ;-). Shutting > down the sending side is a pretty standard pattern for a TCP service. > But well, these days the Internet virtually runs on HTTP 1.0 only. Heh, backwards compatible to NCP perhaps too, while we're at it? :-) SKS itself still is compatible here. Unfortunately, SKS is single-threaded and sees one request through to completion, so it's unsafe to expose directly as one bad actor can lock up the keyserver for everyone else. So current best practice for deployment is to put a reverse proxy in front of SKS, with that reverse proxy handling buffering and slow clients, letting SKS get on with the next request. See the keyservers marked with green in the RProx column at: http://www.sks-keyservers.net/status/ Unfortunately, this change in practice is recent enough that we're still shaking out the bad interactions caused by adding another moving part to the mix. nginx is a popular choice of reverse proxy, and it treats the shutdown as a connection abort by default. Various OS/patch combinations might make this impossible to disable. We've figured out what should be done. Some keyserver operators have made the change, but because triggering the bad interaction is very timing sensitive, we can't reliably detect setups which haven't, so can't sensibly exclude them from the keyserver pools. http://www.sks-keyservers.net/overview-of-pools.php If anyone is interested in what we currently suggest for keyserver operators, the wiki page on Peering is the place to start: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering and new keyserver operators are always welcome! Regards, -Phil, dogsbody debugger From achim at pietig.com Mon Mar 4 10:12:11 2013 From: achim at pietig.com (Achim Pietig) Date: Mon, 04 Mar 2013 10:12:11 +0100 Subject: Delete key from OpenPGP card? In-Reply-To: <513451E2.4080305@mbm.vn> References: <513451E2.4080305@mbm.vn> Message-ID: <5134656B.7040201@pietig.com> Hi, several data objects have a fixed lenght, in the specification DO 'C9' is defined with 20 bytes. The card checks the correct length for PUT DATA. Variable lenght DOs are defined with length from 0 to max or min to max. Virgin cards have a content of 20 bytes with '00' in fingerprint and other fixed lenght DOs. To delete a fingerprint you have to write 20 zeros to the DO: 00 DA 00 C9 14 000000 ... Regards, Achim Am 04.03.2013 08:48, schrieb Nguy?n H?ng Qu?n: > Hello, > > I'm implementing "delete key" in OpenSC for OpenPGP card. > To delete authentication key, for example, I think I have to empty these > DOs: > - 00C9, containing fingerprint for the key > - 00D0, containing creation time for the key > and rewrite the Extended header list with 00DB command. > > However, I failed to empty 00C9. I tried these APDU: > 1. 00 DA 00 C9 > Return error 6700 (Wrong length) > 2. 00 DA 00 C9 00 > Return error 6400 (Execution error) > > The 1st form, I tried with normal DO, like 005B, and succeeded. > The 2nd form, I referenced > https://gitorious.org/gnuk/gnuk/blobs/master/tool/gnuk_remove_keys.py#line98 > (This script is for Gnuk card and success with Gnuk). > > Why none of these APDU work with OpenPGP card? What is the correct APDU > for OpenPGP? > From quannguyen at mbm.vn Mon Mar 4 10:24:54 2013 From: quannguyen at mbm.vn (=?UTF-8?B?Tmd1eeG7hW4gSOG7k25nIFF1w6Ju?=) Date: Mon, 04 Mar 2013 16:24:54 +0700 Subject: Delete key from OpenPGP card? In-Reply-To: <513451E2.4080305@mbm.vn> References: <513451E2.4080305@mbm.vn> Message-ID: <51346866.5090708@mbm.vn> Thanks Achim, How's about emptying Extended Header List I tried to put these data to 004D tag, but none of them works. - 4D 08 A400 7F48 00 5F48 00 (null data to 7848 and 5F48) - 4D 10 A400 7F48 08 9100 9200 9300 9500 5F48 00 (null data to 91 (exponent), 92 (p), 93 (q), 95 (modulus) and null data to 5F48) - 4D 13 A400 7F48 0B 9103010001 9200 9300 9500 5F48 00 (like above, but set default value (010001) for exponent) I use 95 as modulus holder, instead of 97, because I look in to GnuPG source and found 95 is used. What's the correct APDU, or correct data to reset Extended Header List? Thanks. On Mon 04 Mar 2013 02:48:50 PM ICT, Nguy?n H?ng Qu?n wrote: > Hello, > > I'm implementing "delete key" in OpenSC for OpenPGP card. > To delete authentication key, for example, I think I have to empty these > DOs: > - 00C9, containing fingerprint for the key > - 00D0, containing creation time for the key > and rewrite the Extended header list with 00DB command. > > However, I failed to empty 00C9. I tried these APDU: > 1. 00 DA 00 C9 > Return error 6700 (Wrong length) > 2. 00 DA 00 C9 00 > Return error 6400 (Execution error) > > The 1st form, I tried with normal DO, like 005B, and succeeded. > The 2nd form, I referenced > https://gitorious.org/gnuk/gnuk/blobs/master/tool/gnuk_remove_keys.py#line98 > (This script is for Gnuk card and success with Gnuk). > > Why none of these APDU work with OpenPGP card? What is the correct APDU > for OpenPGP? > -- Regards, Qu?n Y!IM: ng_hquan_vn GTalk: ng.hong.quan From quannguyen at mbm.vn Mon Mar 4 08:48:50 2013 From: quannguyen at mbm.vn (=?UTF-8?B?Tmd1eeG7hW4gSOG7k25nIFF1w6Ju?=) Date: Mon, 04 Mar 2013 14:48:50 +0700 Subject: Delete key from OpenPGP card? Message-ID: <513451E2.4080305@mbm.vn> Hello, I'm implementing "delete key" in OpenSC for OpenPGP card. To delete authentication key, for example, I think I have to empty these DOs: - 00C9, containing fingerprint for the key - 00D0, containing creation time for the key and rewrite the Extended header list with 00DB command. However, I failed to empty 00C9. I tried these APDU: 1. 00 DA 00 C9 Return error 6700 (Wrong length) 2. 00 DA 00 C9 00 Return error 6400 (Execution error) The 1st form, I tried with normal DO, like 005B, and succeeded. The 2nd form, I referenced https://gitorious.org/gnuk/gnuk/blobs/master/tool/gnuk_remove_keys.py#line98 (This script is for Gnuk card and success with Gnuk). Why none of these APDU work with OpenPGP card? What is the correct APDU for OpenPGP? -- Regards, Qu?n Y!IM: ng_hquan_vn GTalk: ng.hong.quan From wk at gnupg.org Mon Mar 4 11:09:22 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2013 11:09:22 +0100 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130304081312.GA65178@redoubt.spodhuis.org> (Phil Pennock's message of "Mon, 4 Mar 2013 03:13:12 -0500") References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <1362076981.20807.1.camel@fermat.scientia.net> <87txoswjcd.fsf@vigenere.g10code.de> <20130304081312.GA65178@redoubt.spodhuis.org> Message-ID: <874ngrwk6l.fsf@vigenere.g10code.de> On Mon, 4 Mar 2013 09:13, gnupg-devel at spodhuis.org said: > SKS itself still is compatible here. Unfortunately, SKS is > single-threaded and sees one request through to completion, so it's You mean there is just an accept() waiting for a connection and than handling it. Instead of having a select loop which handles all network I/O (via closures, threads, or fork). Please tell me that this is not true. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From quannguyen at mbm.vn Mon Mar 4 11:29:07 2013 From: quannguyen at mbm.vn (=?UTF-8?B?Tmd1eeG7hW4gSOG7k25nIFF1w6Ju?=) Date: Mon, 04 Mar 2013 17:29:07 +0700 Subject: Delete key from OpenPGP card? In-Reply-To: <51346866.5090708@mbm.vn> References: <513451E2.4080305@mbm.vn> <51346866.5090708@mbm.vn> Message-ID: <51347773.6060408@mbm.vn> Hi Achim, I made mistake about using 95 as modulus holder. I check GnuPG again and it does not use this number. I was wrong. Very sorry. On Mon 04 Mar 2013 04:24:54 PM ICT, Nguy?n H?ng Qu?n wrote: > > I use 95 as modulus holder, instead of 97, because I look in to GnuPG > source and found 95 is used. -- Regards, Qu?n Y!IM: ng_hquan_vn GTalk: ng.hong.quan From achim at pietig.com Mon Mar 4 11:35:42 2013 From: achim at pietig.com (Achim Pietig) Date: Mon, 04 Mar 2013 11:35:42 +0100 Subject: Delete key from OpenPGP card? In-Reply-To: <51346866.5090708@mbm.vn> References: <513451E2.4080305@mbm.vn> <51346866.5090708@mbm.vn> Message-ID: <513478FE.7000908@pietig.com> Hi, OK, i see the problem... The deletion of a single key was no requirement for the OpenPGP card up to now. It is assumed that a key for sig, aut and dec will be replaced after expiring. The import of a key with the header list checks the correctness of the new key so it is not possible to overwrite with zeros etc. The only way at the moment is to reset the card completely, with loss of all information. If the keys were generated outside and imported, then a restore of the card may be possible. Deletion of keys is defined for optional functions like secure messaging, but not for the main keys... If useful and needed we can add this for the next version of the specification. ISO 7816-8 actual works on commands like Delete key/password... Regards, Achim Am 04.03.2013 10:24, schrieb Nguy?n H?ng Qu?n: > Thanks Achim, > > How's about emptying Extended Header List > I tried to put these data to 004D tag, but none of them works. > - 4D 08 A400 7F48 00 5F48 00 > (null data to 7848 and 5F48) > - 4D 10 A400 7F48 08 9100 9200 9300 9500 5F48 00 > (null data to 91 (exponent), 92 (p), 93 (q), 95 (modulus) and null data > to 5F48) > - 4D 13 A400 7F48 0B 9103010001 9200 9300 9500 5F48 00 > (like above, but set default value (010001) for exponent) > > I use 95 as modulus holder, instead of 97, because I look in to GnuPG > source and found 95 is used. > > What's the correct APDU, or correct data to reset Extended Header List? > > Thanks. > > On Mon 04 Mar 2013 02:48:50 PM ICT, Nguy?n H?ng Qu?n wrote: >> Hello, >> >> I'm implementing "delete key" in OpenSC for OpenPGP card. >> To delete authentication key, for example, I think I have to empty these >> DOs: >> - 00C9, containing fingerprint for the key >> - 00D0, containing creation time for the key >> and rewrite the Extended header list with 00DB command. >> >> However, I failed to empty 00C9. I tried these APDU: >> 1. 00 DA 00 C9 >> Return error 6700 (Wrong length) >> 2. 00 DA 00 C9 00 >> Return error 6400 (Execution error) >> >> The 1st form, I tried with normal DO, like 005B, and succeeded. >> The 2nd form, I referenced >> https://gitorious.org/gnuk/gnuk/blobs/master/tool/gnuk_remove_keys.py#line98 >> (This script is for Gnuk card and success with Gnuk). >> >> Why none of these APDU work with OpenPGP card? What is the correct APDU >> for OpenPGP? >> > > -- > Regards, > Qu?n > > Y!IM: ng_hquan_vn > GTalk: ng.hong.quan > > From gnupg-devel at spodhuis.org Mon Mar 4 11:48:08 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 4 Mar 2013 05:48:08 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <874ngrwk6l.fsf@vigenere.g10code.de> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <1362076981.20807.1.camel@fermat.scientia.net> <87txoswjcd.fsf@vigenere.g10code.de> <20130304081312.GA65178@redoubt.spodhuis.org> <874ngrwk6l.fsf@vigenere.g10code.de> Message-ID: <20130304104808.GA67226@redoubt.spodhuis.org> On 2013-03-04 at 11:09 +0100, Werner Koch wrote: > On Mon, 4 Mar 2013 09:13, gnupg-devel at spodhuis.org said: > > SKS itself still is compatible here. Unfortunately, SKS is > > single-threaded and sees one request through to completion, so it's > > You mean there is just an accept() waiting for a connection and than > handling it. Instead of having a select loop which handles all network > I/O (via closures, threads, or fork). > > Please tell me that this is not true. It's O'Caml, so not quite literally, but otherwise yes, that's true. Thus the reverse proxies. The software was, as I understand matters, written as an academic project. It has never been ported to a concurrency library. It's O'Caml, which limits the audience of programmers capable of rewriting to be concurrent. I certainly couldn't: I've fixed various bugs, but am not going to pretend I could re-architect. Hockeypuck is looking interesting. Written in Go, is fully concurrent, and implementing the SKS reconciliation part. Author's instance is running at: http://keyserver.gazzang.net/ Summary of the keyserver code-bases I know of: http://people.spodhuis.org/phil.pennock/pgp-keyservers Pointers to others appreciated. -Phil From wk at gnupg.org Mon Mar 4 14:37:48 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2013 14:37:48 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Wed, 27 Feb 2013 13:19:21 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> <87y5ejgx0m.fsf@vigenere.g10code.de> Message-ID: <87d2vfuvyr.fsf@vigenere.g10code.de> On Wed, 27 Feb 2013 20:19, lailavrazda1979 at gmail.com said: > With the latest version of libassuan, HAVE_DOSISH_SYSTEM is still not > defined for target x86_64-w64-mingw32. x86_64-w64-mingw32 creates 64 bit Windows binaries - right? case "${host}" in [...] x86_64-*mingw32*) have_w32_system=yes have_w64_system=yes ;; *-mingw32ce*) have_dosish_system=yes have_w32_system=yes have_w32ce_system=yes ;; *-mingw32*) have_dosish_system=yes have_w32_system=yes ;; [...] The first listed case defines have_w64_system and the last case is used for 32 bit Windows. However, as I already explained several times: Libassuan and the whole GnuPG system can't be build for W64 (64 bit Windows binaries). Even if we already define some variables; this does not mean W64 is supported! Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Mar 4 14:42:29 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2013 14:42:29 +0100 Subject: lber link error in gnupg-2.1.0beta3/dirmngr In-Reply-To: <5132C59A.9000307@GingerBear.net> (John Clizbe's message of "Sat, 02 Mar 2013 21:38:02 -0600") References: <5132C59A.9000307@GingerBear.net> Message-ID: <878v63uvqy.fsf@vigenere.g10code.de> On Sun, 3 Mar 2013 04:38, JPClizbe at gingerbear.net said: > Adding -llber to the LDAPLIBS value in dirmngr/Makefile fixes the problem, but > it'd probably be better if configure handled it. This has been fixed in master more than a year ago. Unfortunately beta3 is even 2 months older. I hope to do a beta 4 this months, but before that a Libgcrypt maintenance release is due. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Mar 4 14:50:16 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2013 14:50:16 +0100 Subject: Delete key from OpenPGP card? In-Reply-To: <513478FE.7000908@pietig.com> (Achim Pietig's message of "Mon, 04 Mar 2013 11:35:42 +0100") References: <513451E2.4080305@mbm.vn> <51346866.5090708@mbm.vn> <513478FE.7000908@pietig.com> Message-ID: <874ngruvdz.fsf@vigenere.g10code.de> On Mon, 4 Mar 2013 11:35, achim at pietig.com said: > If useful and needed we can add this for the next version of the specification. > ISO 7816-8 actual works on commands like Delete key/password... That is not needed. It is far easier to store a dummy key on the card [1] Salam-Shalom, Werner [1] If you want to use a well-known key, you may generate it using a test program distributed with Libgcrypt master: In the build directory run "tests/prime --42" and use a key with these parameters. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Mar 4 15:29:50 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Mar 2013 15:29:50 +0100 Subject: gpgme-1.4.0 test hang In-Reply-To: (Nelson H. F. Beebe's message of "Sat, 2 Mar 2013 09:37:20 -0700 (MST)") References: Message-ID: <87obeztezl.fsf@vigenere.g10code.de> On Sat, 2 Mar 2013 17:37, beebe at math.utah.edu said: > I've made attempts to build gpgme-1.4.0 on more than two dozen flavors > of Unix, with very limited success. On several systems, the build > completes, and the check runs through several tests, then reaches this Would it be possible for you to run GPGME_DEBUG=9:gpgme.log tests/gpgsm/t-verify gzip gpgme.log and send it to me? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp at brainhub.org Tue Mar 5 06:44:51 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Mon, 04 Mar 2013 21:44:51 -0800 Subject: OpenPGP card specification enhancement for ECDSA support In-Reply-To: <1362359940.2678.2.camel@cfw2.gniibe.org> References: <1362118942.6222.1.camel@cfw2.gniibe.org> <5130FB3A.7060307@brainhub.org> <1362215529.2962.1.camel@cfw2.gniibe.org> <1362359940.2678.2.camel@cfw2.gniibe.org> Message-ID: <51358653.6080803@brainhub.org> Hello NIIBE, I agree that you would want to support uncompressed ECC key representation at least because you never know where a key came from. Having said this, GnuPG should change the key generation to generate "compliant" keys all the time. I do this in my software. There is no reason not to do so. This gives an option to use an efficient representation down the road, but that's not a requirement. One can still encode a compliant key per RFC6637 (uncompressed). I can volunteer to write a patch for the compliant key generation for GnuPG when I find time. On 03/03/2013 05:19 PM, NIIBE Yutaka wrote: > Hello Andrey, > > On 2013-03-02 at 18:12 +0900, NIIBE Yutaka wrote: >> On 2013-03-01 at 11:02 -0800, Andrey Jivsov wrote: >>> Please consider using the compact representation of an ECC point: >>> http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card. >> >> Thank you very much. I didn't know this document. All that I had >> known about compression was x + (1-bit of y). > > I considered again. > > For new keys, we will be able to take advantage of this compact > representation. But, there are already ECDSA keys out there. > > I will limit key space for Gnuk for new keys, so that keys generated > on Gnuk Token can be represented by the compact representation. But, > note that most users of Gnuk use writekey command, generating keys on > host PC. > > I think that Gnuk Token should not limit key space for writekey > command (host PC -> Gnuk Token), but should accept keys of other half > space for inter-operablity. > > Speaking for GnuPG, same argument could be applied. > > It is true that there has been no released versions which support > ECDSA yet. But, it should handle any keys by any OpenPGP ECC > implementations. Besides, GnuPG supports SSH and X.509. With the > possibility of 50%, existing keys of ECDSA couldn't be represented by > the compact representation. I think that GnuPG should handle both of > the compact representation and the uncompressed representation. > From gniibe at fsij.org Tue Mar 5 09:07:41 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 05 Mar 2013 17:07:41 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <51320E1F.8030009@pietig.com> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <50EE75B5.3090009@pietig.com> <1358217413.2667.6.camel@cfw2.gniibe.org> <51320E1F.8030009@pietig.com> Message-ID: <1362470861.2860.7.camel@cfw2.gniibe.org> On 2013-03-02 at 15:35 +0100, Achim Pietig wrote: > PC/SC V2: Interoperability Specification for ICCs and Personal Computer Systems, Part 10 IFDs with Secure PIN Entry Capabilities, Revision 2.02.09 November 2012 > Secoder 2: from german banks (GeldKarte), not public available Thanks for your references. > If the support of readers for alpha passwords with variable length > is too complex, a next version of the OpenPGP card may support PIN > 2-block too, but then an algorithm ID or a usage flag in Extended > capabilies is needed. What do you think? No, the support of readers (for alpha passwords and/or with variable length) is not that difficult, in terms of GnuPG implementation. From users point of view, it is a bit complicated to configure fixed length PIN input, though. My own problem was one of my readers doesn't support variable length PIN input. And I thought that such readers were common. Anyway, such readers are supported by fixed length PIN input. Adding format 2 PIN block make sense if: (1) Readers which don't support variable length PIN input are common. AND (2) Readers work well for encoding nibbles for PIN input. AND (3) Users wants no configuration for fixed length PIN input. Given the condition (1) is (or will soon be) not true any more, adding format 2 PIN block is not worth. Users deserve to be required to configure for not-so-common readers. -- From dkg at fifthhorseman.net Tue Mar 5 10:24:54 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 5 Mar 2013 04:24:54 -0500 Subject: [PATCH] update RFC references to RFC 4880 Message-ID: <1362475494-1063-1-git-send-email-dkg@fifthhorseman.net> --- doc/gpg.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index cf647e1..0462c9e 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2418,7 +2418,7 @@ check. @code{value} may be any printable string; it will be encoded in UTF8, so you should check that your @option{--display-charset} is set correctly. If you prefix @code{name} with an exclamation mark (!), the notation data will be flagged as critical -(rfc2440:5.2.3.15). @option{--sig-notation} sets a notation for data +(rfc4880:5.2.3.16). @option{--sig-notation} sets a notation for data signatures. @option{--cert-notation} sets a notation for key signatures (certifications). @option{--set-notation} sets both. @@ -2440,7 +2440,7 @@ meaningful when using the OpenPGP smartcard. @opindex sig-policy-url @opindex cert-policy-url @opindex set-policy-url -Use @code{string} as a Policy URL for signatures (rfc2440:5.2.3.19). If +Use @code{string} as a Policy URL for signatures (rfc4880:5.2.3.20). If you prefix it with an exclamation mark (!), the policy URL packet will be flagged as critical. @option{--sig-policy-url} sets a policy url for data signatures. @option{--cert-policy-url} sets a policy url for key -- 1.7.10.4 From lailavrazda1979 at gmail.com Wed Mar 6 00:30:38 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Tue, 5 Mar 2013 17:30:38 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87d2vfuvyr.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> <87y5ejgx0m.fsf@vigenere.g10code.de> <87d2vfuvyr.fsf@vigenere.g10code.de> Message-ID: On Mon, Mar 4, 2013 at 7:37 AM, Werner Koch wrote: > On Wed, 27 Feb 2013 20:19, lailavrazda1979 at gmail.com said: > > With the latest version of libassuan, HAVE_DOSISH_SYSTEM is still not > > defined for target x86_64-w64-mingw32. > > x86_64-w64-mingw32 creates 64 bit Windows binaries - right? > > case "${host}" in > [...] > > x86_64-*mingw32*) > have_w32_system=yes > have_w64_system=yes > ;; > *-mingw32ce*) > have_dosish_system=yes > have_w32_system=yes > have_w32ce_system=yes > ;; > *-mingw32*) > have_dosish_system=yes > have_w32_system=yes > ;; > [...] > > The first listed case defines have_w64_system and the last case is used > for 32 bit Windows. However, as I already explained several times: > Libassuan and the whole GnuPG system can't be build for W64 (64 bit > Windows binaries). Even if we already define some variables; this does > not mean W64 is supported! > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > If you define some variables, it implies you're trying to move toward supporting W64, and this will only take one line to fix. Unless you plan on never supporting modern Windows systems? -------------- next part -------------- An HTML attachment was scrubbed... URL: From x-alina at gmx.net Wed Mar 6 04:24:50 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 06 Mar 2013 04:24:50 +0100 Subject: Pinpad support for REINER SCT cyberJack go Message-ID: <20130306032450.237000@gmx.net> Hello, I have bought a REINER SCT cyberJack go. It's a CCID device. Decryption and sign works, but it don't it's built-in pinpad. GnuPG uses pcscd. I can't get the internal driver to work. How can I add pinpad support for this reader? I use GnuPG 2.0.19, build from source. lsusb: ID 0c4b:0504 Reiner SCT Kartensysteme GmbH gpg2: gpg: detected reader `REINER SCT cyberJack go (4603989351) 00 00' Regards, Alina From gniibe at fsij.org Wed Mar 6 07:14:26 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Mar 2013 15:14:26 +0900 Subject: Pinpad support for REINER SCT cyberJack go In-Reply-To: <20130306032450.237000@gmx.net> References: <20130306032450.237000@gmx.net> Message-ID: <1362550466.6013.0.camel@cfw2.gniibe.org> On 2013-03-06 at 04:24 +0100, Alina Friedrichsen wrote: > I use GnuPG 2.0.19, build from source. In 2.0.19. pinpad input is not supported through PC/SC. The pinpad input feature for PC/SC has been added both of master and STABLE-BRANCH-2.0. You will be able to use it with forthcoming 2.0.20. (You will need to add enable-pinpad-varlen option for ./gnupg/scdaemon.conf.) > lsusb: > ID 0c4b:0504 Reiner SCT Kartensysteme GmbH > > gpg2: > gpg: detected reader `REINER SCT cyberJack go (4603989351) 00 00' I got a report that following card reader works fine: 0c4b:0500 Reiner SCT Kartensysteme GmbH "REINER SCT cyberJack RFID standard (7592671050) 00 00" Since it seems that your reader is newer than that, I hope that it works well, too. Besides, for both of master and STABLE-BRANCH-2.0, internal CCID driver got improved. I think that you can use your reader without PC/SC. If it works, it is better for your reader to be added to good readers list of enable_varlen=1 in scd/ccid-driver.c so that you don't need to configure. If you have enough time, please try STABLE-BRANCH-2.0 of git.gnupg.org. Or else, please wait for 2.0.20. -- From wk at gnupg.org Wed Mar 6 10:15:46 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Mar 2013 10:15:46 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Tue, 5 Mar 2013 17:30:38 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> <87y5ejgx0m.fsf@vigenere.g10code.de> <87d2vfuvyr.fsf@vigenere.g10code.de> Message-ID: <8738w8lwhp.fsf@vigenere.g10code.de> On Wed, 6 Mar 2013 00:30, lailavrazda1979 at gmail.com said: > If you define some variables, it implies you're trying to move toward > supporting W64, and this will only take one line to fix. Unless you plan on > never supporting modern Windows systems? Please check the other messages; I said several times that there is no support for Windows 64. Except for GpgEX, 32 bit works just fine on 64 bit Windows boxes. If you need native 64 bit applications, please help us to get funding for this. BTW: You should read http://www.netmeister.org/news/learn2quote.html . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Wed Mar 6 18:18:10 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 06 Mar 2013 18:18:10 +0100 Subject: Pinpad support for REINER SCT cyberJack go In-Reply-To: <1362550466.6013.0.camel@cfw2.gniibe.org> References: <20130306032450.237000@gmx.net> <1362550466.6013.0.camel@cfw2.gniibe.org> Message-ID: <20130306171810.33030@gmx.net> I wrote a patch, but I can't compile gnupg from git yet. Is here a other developer from Berlin? -------- Original-Nachricht -------- > Datum: Wed, 06 Mar 2013 15:14:26 +0900 > Von: NIIBE Yutaka > An: Alina Friedrichsen > CC: gnupg-devel at gnupg.org > Betreff: Re: Pinpad support for REINER SCT cyberJack go > On 2013-03-06 at 04:24 +0100, Alina Friedrichsen wrote: > > I use GnuPG 2.0.19, build from source. > > In 2.0.19. pinpad input is not supported through PC/SC. > > The pinpad input feature for PC/SC has been added both of master and > STABLE-BRANCH-2.0. You will be able to use it with forthcoming > 2.0.20. (You will need to add enable-pinpad-varlen option for > ./gnupg/scdaemon.conf.) > > > lsusb: > > ID 0c4b:0504 Reiner SCT Kartensysteme GmbH > > > > gpg2: > > gpg: detected reader `REINER SCT cyberJack go (4603989351) 00 00' > > I got a report that following card reader works fine: > > 0c4b:0500 Reiner SCT Kartensysteme GmbH > "REINER SCT cyberJack RFID standard (7592671050) 00 00" > > Since it seems that your reader is newer than that, I hope that it > works well, too. > > Besides, for both of master and STABLE-BRANCH-2.0, internal CCID > driver got improved. I think that you can use your reader without > PC/SC. If it works, it is better for your reader to be added > to good readers list of enable_varlen=1 in scd/ccid-driver.c > so that you don't need to configure. > > If you have enough time, please try STABLE-BRANCH-2.0 of > git.gnupg.org. Or else, please wait for 2.0.20. > -- > > -------------- next part -------------- A non-text attachment was scrubbed... Name: cyberjack_go.patch Type: text/x-patch Size: 957 bytes Desc: not available URL: From lailavrazda1979 at gmail.com Wed Mar 6 20:35:00 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Wed, 6 Mar 2013 13:35:00 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <8738w8lwhp.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> <87y5ejgx0m.fsf@vigenere.g10code.de> <87d2vfuvyr.fsf@vigenere.g10code.de> <8738w8lwhp.fsf@vigenere.g10code.de> Message-ID: > If you need native 64 bit applications, please help us to get funding for > this. I can do better than that, I'll help develop and test it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From x-alina at gmx.net Wed Mar 6 23:37:29 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 06 Mar 2013 23:37:29 +0100 Subject: Pinpad support for REINER SCT cyberJack go In-Reply-To: <1362550466.6013.0.camel@cfw2.gniibe.org> References: <20130306032450.237000@gmx.net> <1362550466.6013.0.camel@cfw2.gniibe.org> Message-ID: <20130306223729.33040@gmx.net> Now I have all dependencies to run "./configure", but "make" breaks with the following error message: make[2]: *** No rule to make target `audit-events.h', needed by `all'. Stop. make[2]: Leaving directory `/home/x-alina/Downloads/gnupg/common' -------- Original-Nachricht -------- > Datum: Wed, 06 Mar 2013 15:14:26 +0900 > Von: NIIBE Yutaka > An: Alina Friedrichsen > CC: gnupg-devel at gnupg.org > Betreff: Re: Pinpad support for REINER SCT cyberJack go > On 2013-03-06 at 04:24 +0100, Alina Friedrichsen wrote: > > I use GnuPG 2.0.19, build from source. > > In 2.0.19. pinpad input is not supported through PC/SC. > > The pinpad input feature for PC/SC has been added both of master and > STABLE-BRANCH-2.0. You will be able to use it with forthcoming > 2.0.20. (You will need to add enable-pinpad-varlen option for > ./gnupg/scdaemon.conf.) > > > lsusb: > > ID 0c4b:0504 Reiner SCT Kartensysteme GmbH > > > > gpg2: > > gpg: detected reader `REINER SCT cyberJack go (4603989351) 00 00' > > I got a report that following card reader works fine: > > 0c4b:0500 Reiner SCT Kartensysteme GmbH > "REINER SCT cyberJack RFID standard (7592671050) 00 00" > > Since it seems that your reader is newer than that, I hope that it > works well, too. > > Besides, for both of master and STABLE-BRANCH-2.0, internal CCID > driver got improved. I think that you can use your reader without > PC/SC. If it works, it is better for your reader to be added > to good readers list of enable_varlen=1 in scd/ccid-driver.c > so that you don't need to configure. > > If you have enough time, please try STABLE-BRANCH-2.0 of > git.gnupg.org. Or else, please wait for 2.0.20. > -- > > From gniibe at fsij.org Thu Mar 7 00:31:13 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Mar 2013 08:31:13 +0900 Subject: Pinpad support for REINER SCT cyberJack go In-Reply-To: <20130306223729.33040@gmx.net> References: <20130306032450.237000@gmx.net> <1362550466.6013.0.camel@cfw2.gniibe.org> <20130306223729.33040@gmx.net> Message-ID: <1362612673.2653.0.camel@cfw2.gniibe.org> On 2013-03-06 at 23:37 +0100, Alina Friedrichsen wrote: > Now I have all dependencies to run "./configure", > but "make" breaks with the following error message: > > make[2]: *** No rule to make target `audit-events.h', needed by `all'. Stop. Please read gnupg/README.GIT. In the Git repository, we don't have some files which can be generated. The file, gnupg/common/audit-events.h, is one of that. You need to run autogen.sh and invoke configure with --enable-maintainer-mode. Then, gnupg/common/audit-events.h will be generated on your next make invocation. Thank you for your cooperation. -- From mail at tgries.de Thu Mar 7 00:37:39 2013 From: mail at tgries.de (Thomas Gries) Date: Thu, 07 Mar 2013 00:37:39 +0100 Subject: Pinpad support for REINER SCT cyberJack go In-Reply-To: <1362612673.2653.0.camel@cfw2.gniibe.org> References: <20130306032450.237000@gmx.net> <1362550466.6013.0.camel@cfw2.gniibe.org> <20130306223729.33040@gmx.net> <1362612673.2653.0.camel@cfw2.gniibe.org> Message-ID: <5137D343.4020900@tgries.de> Am 07.03.2013 00:31, schrieb NIIBE Yutaka: > On 2013-03-06 at 23:37 +0100, Alina Friedrichsen wrote: >> Now I have all dependencies to run "./configure", >> but "make" breaks with the following error message: >> >> make[2]: *** No rule to make target `audit-events.h', needed by `all'. Stop. > Please read gnupg/README.GIT. In the Git repository, we don't have > some files which can be generated. The file, > gnupg/common/audit-events.h, is one of that. > > You need to run autogen.sh and invoke configure with > --enable-maintainer-mode. > > Then, gnupg/common/audit-events.h will be generated on your next make > invocation. > > Thank you for your cooperation. I made a "download all repos and dependencies for gnupg from git and compile" script for Linux. Will publish that soon. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Mar 7 06:01:51 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Mar 2013 14:01:51 +0900 Subject: [PATCH] scd: support ECDSA public key In-Reply-To: <1362026284.3220.2.camel@cfw2.gniibe.org> References: <1362026284.3220.2.camel@cfw2.gniibe.org> Message-ID: <1362632511.2653.8.camel@cfw2.gniibe.org> On 2013-02-28 at 13:38 +0900, NIIBE Yutaka wrote: > Here is another patch for GnuPG in the smartcard ECDSA support series. Here is update. This assume the format of public key, as: > Data Object Abbrev. Tag Type Certificate > Object Identifier 0x06 Object Identifier m (mandatory) [...] > Public point Y 0x86 Elliptic Curve Point m I'll commit this patch to master, if no objections. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 23b28c3..8d507c4 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -116,6 +116,16 @@ static struct { }; +/* Type of keys. */ +typedef enum + { + KEY_TYPE_ECDH, + KEY_TYPE_ECDSA, + KEY_TYPE_RSA, + } +key_type_t; + + /* The format of RSA private keys. */ typedef enum { @@ -128,6 +138,15 @@ typedef enum rsa_key_format_t; +/* Elliptic Curves. */ +enum + { + CURVE_NIST_P256, + CURVE_NIST_P384, + CURVE_NIST_P521 + }; + + /* One cache item for DOs. */ struct cache_s { struct cache_s *next; @@ -199,15 +218,27 @@ struct app_local_s { int fixedlen_admin; } pinpad; - struct - { - unsigned int n_bits; /* Size of the modulus in bits. The rest - of this strucuire is only valid if - this is not 0. */ - unsigned int e_bits; /* Size of the public exponent in bits. */ - rsa_key_format_t format; - } keyattr[3]; - + struct + { + key_type_t key_type; + union { + struct { + unsigned int n_bits; /* Size of the modulus in bits. The rest + of this strucuire is only valid if + this is not 0. */ + unsigned int e_bits; /* Size of the public exponent in bits. */ + rsa_key_format_t format; + } rsa; + struct { + int curve; + } ecdsa; + struct { + int curve; + int hashalgo; + int cipheralgo; + } ecdh; + }; + } keyattr[3]; }; @@ -845,18 +876,59 @@ send_key_data (ctrl_t ctrl, const char *name, static void +get_ecc_key_parameters (int curve, int *r_n_bits, const char **r_curve_oid) +{ + if (curve == CURVE_NIST_P256) + { + *r_n_bits = 256; + *r_curve_oid = "1.2.840.10045.3.1.7"; + } + else if (curve == CURVE_NIST_P384) + { + *r_n_bits = 384; + *r_curve_oid = "1.3.132.0.34"; + } + else + { + *r_n_bits = 521; + *r_curve_oid = "1.3.132.0.35"; + } +} + +static void send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) { char buffer[200]; + int n_bits; + const char *curve_oid; assert (number >=0 && number < DIM(app->app_local->keyattr)); - /* We only support RSA thus the algo identifier is fixed to 1. */ - snprintf (buffer, sizeof buffer, "%d 1 %u %u %d", - number+1, - app->app_local->keyattr[number].n_bits, - app->app_local->keyattr[number].e_bits, - app->app_local->keyattr[number].format); + if (app->app_local->keyattr[number].key_type == KEY_TYPE_RSA) + snprintf (buffer, sizeof buffer, "%d 1 %u %u %d", + number+1, + app->app_local->keyattr[number].rsa.n_bits, + app->app_local->keyattr[number].rsa.e_bits, + app->app_local->keyattr[number].rsa.format); + else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECDSA) + { + get_ecc_key_parameters (app->app_local->keyattr[number].ecdsa.curve, + &n_bits, &curve_oid); + snprintf (buffer, sizeof buffer, "%d 19 %u %s", + number+1, n_bits, curve_oid); + } + else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECDH) + { + get_ecc_key_parameters (app->app_local->keyattr[number].ecdh.curve, + &n_bits, &curve_oid); + snprintf (buffer, sizeof buffer, "%d 18 %u %s %d %d", + number+1, n_bits, curve_oid, + app->app_local->keyattr[number].ecdh.hashalgo, + app->app_local->keyattr[number].ecdh.cipheralgo); + } + else + snprintf (buffer, sizeof buffer, "0 0 UNKNOWN"); + send_status_direct (ctrl, keyword, buffer); } @@ -1154,6 +1226,18 @@ retrieve_key_material (FILE *fp, const char *hexkeyid, #endif /*GNUPG_MAJOR_VERSION > 1*/ +static const char * +get_curve_name (int curve) +{ + if (curve == CURVE_NIST_P256) + return "NIST P-256"; + else if (curve == CURVE_NIST_P384) + return "NIST P-384"; + else + return "NIST P-521"; +} + + /* Get the public key for KEYNO and store it as an S-expresion with the APP handle. On error that field gets cleared. If we already know about the public key we will just return. Note that this does @@ -1171,11 +1255,14 @@ get_public_key (app_t app, int keyno) gpg_error_t err = 0; unsigned char *buffer; const unsigned char *keydata, *m, *e; - size_t buflen, keydatalen, mlen, elen; + size_t buflen, keydatalen; + size_t mlen = 0; + size_t elen = 0; unsigned char *mbuf = NULL; unsigned char *ebuf = NULL; char *keybuf = NULL; - char *keybuf_p; + gcry_sexp_t s_pkey; + size_t len; if (keyno < 1 || keyno > 3) return gpg_error (GPG_ERR_INV_ID); @@ -1227,51 +1314,34 @@ get_public_key (app_t app, int keyno) goto leave; } - m = find_tlv (keydata, keydatalen, 0x0081, &mlen); - if (!m) + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) { - err = gpg_error (GPG_ERR_CARD); - log_error (_("response does not contain the RSA modulus\n")); - goto leave; - } - - - e = find_tlv (keydata, keydatalen, 0x0082, &elen); - if (!e) - { - err = gpg_error (GPG_ERR_CARD); - log_error (_("response does not contain the RSA public exponent\n")); - goto leave; - } + m = find_tlv (keydata, keydatalen, 0x0081, &mlen); + if (!m) + { + err = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the RSA modulus\n")); + goto leave; + } - /* Prepend numbers with a 0 if needed. */ - if (mlen && (*m & 0x80)) - { - mbuf = xtrymalloc ( mlen + 1); - if (!mbuf) + e = find_tlv (keydata, keydatalen, 0x0082, &elen); + if (!e) { - err = gpg_error_from_syserror (); + err = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the RSA public exponent\n")); goto leave; } - *mbuf = 0; - memcpy (mbuf+1, m, mlen); - mlen++; - m = mbuf; } - if (elen && (*e & 0x80)) + else { - ebuf = xtrymalloc ( elen + 1); - if (!ebuf) + m = find_tlv (keydata, keydatalen, 0x0086, &mlen); + if (!m) { - err = gpg_error_from_syserror (); + err = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the EC public point\n")); goto leave; } - *ebuf = 0; - memcpy (ebuf+1, e, elen); - elen++; - e = ebuf; } - } else { @@ -1328,29 +1398,88 @@ get_public_key (app_t app, int keyno) } } - /* Allocate a buffer to construct the S-expression. */ - /* FIXME: We should provide a generalized S-expression creation - mechanism. */ - keybuf = xtrymalloc (50 + 2*35 + mlen + elen + 1); - if (!keybuf) + + mbuf = xtrymalloc ( mlen + 1); + if (!mbuf) { err = gpg_error_from_syserror (); goto leave; } + /* Prepend numbers with a 0 if needed. */ + if (mlen && (*m & 0x80)) + { + *mbuf = 0; + memcpy (mbuf+1, m, mlen); + mlen++; + } + else + memcpy (mbuf, m, mlen); - sprintf (keybuf, "(10:public-key(3:rsa(1:n%u:", (unsigned int) mlen); - keybuf_p = keybuf + strlen (keybuf); - memcpy (keybuf_p, m, mlen); - keybuf_p += mlen; - sprintf (keybuf_p, ")(1:e%u:", (unsigned int)elen); - keybuf_p += strlen (keybuf_p); - memcpy (keybuf_p, e, elen); - keybuf_p += elen; - strcpy (keybuf_p, ")))"); - keybuf_p += strlen (keybuf_p); + ebuf = xtrymalloc ( elen + 1); + if (!ebuf) + { + err = gpg_error_from_syserror (); + goto leave; + } + /* Prepend numbers with a 0 if needed. */ + if (elen && (*e & 0x80)) + { + *ebuf = 0; + memcpy (ebuf+1, e, elen); + elen++; + } + else + memcpy (ebuf, e, elen); + + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) + { + err = gcry_sexp_build (&s_pkey, NULL, "(public-key(rsa(n%b)(e%b)))", + mlen, mbuf, elen, ebuf); + if (err) + goto leave; + + len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); + keybuf = xtrymalloc (len); + if (!keybuf) + { + gcry_sexp_release (s_pkey); + err = gpg_error_from_syserror (); + goto leave; + } + gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); + gcry_sexp_release (s_pkey); + } + else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECDSA) + { + const char *curve_name + = get_curve_name (app->app_local->keyattr[keyno].ecdsa.curve); + + err = gcry_sexp_build (&s_pkey, NULL, + "(public-key(ecdsa(curve%s)(q%b)))", + curve_name, mlen, mbuf); + if (err) + goto leave; + + len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); + + keybuf = xtrymalloc (len); + if (!keybuf) + { + gcry_sexp_release (s_pkey); + err = gpg_error_from_syserror (); + goto leave; + } + gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); + gcry_sexp_release (s_pkey); + } + else + { + err = gpg_error (GPG_ERR_NOT_IMPLEMENTED); + goto leave; + } app->app_local->pk[keyno].key = (unsigned char*)keybuf; - app->app_local->pk[keyno].keylen = (keybuf_p - keybuf); + app->app_local->pk[keyno].keylen = len - 1; /* Decrement for trailing '\0' */ leave: /* Set a flag to indicate that we tried to read the key. */ @@ -2395,7 +2524,7 @@ build_privkey_template (app_t app, int keyno, *result = NULL; *resultlen = 0; - switch (app->app_local->keyattr[keyno].format) + switch (app->app_local->keyattr[keyno].rsa.format) { case RSA_STD: case RSA_STD_N: @@ -2409,7 +2538,7 @@ build_privkey_template (app_t app, int keyno, } /* Get the required length for E. */ - rsa_e_reqlen = app->app_local->keyattr[keyno].e_bits/8; + rsa_e_reqlen = app->app_local->keyattr[keyno].rsa.e_bits/8; assert (rsa_e_len <= rsa_e_reqlen); /* Build the 7f48 cardholder private key template. */ @@ -2425,8 +2554,8 @@ build_privkey_template (app_t app, int keyno, tp += add_tlv (tp, 0x93, rsa_q_len); datalen += rsa_q_len; - if (app->app_local->keyattr[keyno].format == RSA_STD_N - || app->app_local->keyattr[keyno].format == RSA_CRT_N) + if (app->app_local->keyattr[keyno].rsa.format == RSA_STD_N + || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) { tp += add_tlv (tp, 0x97, rsa_n_len); datalen += rsa_n_len; @@ -2478,8 +2607,8 @@ build_privkey_template (app_t app, int keyno, memcpy (tp, rsa_q, rsa_q_len); tp += rsa_q_len; - if (app->app_local->keyattr[keyno].format == RSA_STD_N - || app->app_local->keyattr[keyno].format == RSA_CRT_N) + if (app->app_local->keyattr[keyno].rsa.format == RSA_STD_N + || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) { memcpy (tp, rsa_n, rsa_n_len); tp += rsa_n_len; @@ -2764,7 +2893,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - maxbits = app->app_local->keyattr[keyno].n_bits; + maxbits = app->app_local->keyattr[keyno].rsa.n_bits; nbits = rsa_n? count_bits (rsa_n, rsa_n_len) : 0; if (opt.verbose) log_info ("RSA modulus size is %u bits (%u bytes)\n", @@ -2775,7 +2904,7 @@ do_writekey (app_t app, ctrl_t ctrl, /* Try to switch the key to a new length. */ err = change_keyattr (app, keyno, nbits, pincb, pincb_arg); if (!err) - maxbits = app->app_local->keyattr[keyno].n_bits; + maxbits = app->app_local->keyattr[keyno].rsa.n_bits; } if (nbits != maxbits) { @@ -2785,7 +2914,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - maxbits = app->app_local->keyattr[keyno].e_bits; + maxbits = app->app_local->keyattr[keyno].rsa.e_bits; if (maxbits > 32 && !app->app_local->extcap.is_v2) maxbits = 32; /* Our code for v1 does only support 32 bits. */ nbits = rsa_e? count_bits (rsa_e, rsa_e_len) : 0; @@ -2797,7 +2926,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - maxbits = app->app_local->keyattr[keyno].n_bits/2; + maxbits = app->app_local->keyattr[keyno].rsa.n_bits/2; nbits = rsa_p? count_bits (rsa_p, rsa_p_len) : 0; if (nbits != maxbits) { @@ -2966,7 +3095,7 @@ do_genkey (app_t app, ctrl_t ctrl, const char *keynostr, unsigned int flags, to put a limit on the max. allowed keysize. 2048 bit will already lead to a 527 byte long status line and thus a 4096 bit key would exceed the Assuan line length limit. */ - keybits = app->app_local->keyattr[keyno].n_bits; + keybits = app->app_local->keyattr[keyno].rsa.n_bits; if (keybits > 4096) return gpg_error (GPG_ERR_TOO_LARGE); @@ -3753,6 +3882,22 @@ parse_historical (struct app_local_s *apploc, } +static int +parse_ecc_curve (const unsigned char *buffer, size_t buflen) +{ + int curve; + + if (buflen == 6 && buffer[5] == 0x22) + curve = CURVE_NIST_P384; + else if (buflen == 6 && buffer[5] == 0x23) + curve = CURVE_NIST_P521; + else + curve = CURVE_NIST_P256; + + return curve; +} + + /* Parse and optionally show the algorithm attributes for KEYNO. KEYNO must be in the range 0..2. */ static void @@ -3765,7 +3910,8 @@ parse_algorithm_attribute (app_t app, int keyno) assert (keyno >=0 && keyno <= 2); - app->app_local->keyattr[keyno].n_bits = 0; + app->app_local->keyattr[keyno].key_type = KEY_TYPE_RSA; + app->app_local->keyattr[keyno].rsa.n_bits = 0; relptr = get_one_do (app, 0xC1+keyno, &buffer, &buflen, NULL); if (!relptr) @@ -3784,27 +3930,41 @@ parse_algorithm_attribute (app_t app, int keyno) log_info ("Key-Attr-%s ..: ", desc[keyno]); if (*buffer == 1 && (buflen == 5 || buflen == 6)) { - app->app_local->keyattr[keyno].n_bits = (buffer[1]<<8 | buffer[2]); - app->app_local->keyattr[keyno].e_bits = (buffer[3]<<8 | buffer[4]); - app->app_local->keyattr[keyno].format = 0; + app->app_local->keyattr[keyno].rsa.n_bits = (buffer[1]<<8 | buffer[2]); + app->app_local->keyattr[keyno].rsa.e_bits = (buffer[3]<<8 | buffer[4]); + app->app_local->keyattr[keyno].rsa.format = 0; if (buflen < 6) - app->app_local->keyattr[keyno].format = RSA_STD; + app->app_local->keyattr[keyno].rsa.format = RSA_STD; else - app->app_local->keyattr[keyno].format = (buffer[5] == 0? RSA_STD : - buffer[5] == 1? RSA_STD_N : - buffer[5] == 2? RSA_CRT : - buffer[5] == 3? RSA_CRT_N : - RSA_UNKNOWN_FMT); + app->app_local->keyattr[keyno].rsa.format = (buffer[5] == 0? RSA_STD : + buffer[5] == 1? RSA_STD_N : + buffer[5] == 2? RSA_CRT : + buffer[5] == 3? RSA_CRT_N : + RSA_UNKNOWN_FMT); if (opt.verbose) log_printf ("RSA, n=%u, e=%u, fmt=%s\n", - app->app_local->keyattr[keyno].n_bits, - app->app_local->keyattr[keyno].e_bits, - app->app_local->keyattr[keyno].format == RSA_STD? "std" : - app->app_local->keyattr[keyno].format == RSA_STD_N?"std+n": - app->app_local->keyattr[keyno].format == RSA_CRT? "crt" : - app->app_local->keyattr[keyno].format == RSA_CRT_N?"crt+n":"?"); + app->app_local->keyattr[keyno].rsa.n_bits, + app->app_local->keyattr[keyno].rsa.e_bits, + app->app_local->keyattr[keyno].rsa.format == RSA_STD? "std" : + app->app_local->keyattr[keyno].rsa.format == RSA_STD_N?"std+n": + app->app_local->keyattr[keyno].rsa.format == RSA_CRT? "crt" : + app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N?"crt+n":"?"); + } + else if (*buffer == 19) /* ECDSA */ + { + app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECDSA; + app->app_local->keyattr[keyno].ecdsa.curve + = parse_ecc_curve (buffer + 1, buflen - 1); + } + else if (*buffer == 18 && buflen == 11) /* ECDH */ + { + app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECDH; + app->app_local->keyattr[keyno].ecdh.curve + = parse_ecc_curve (buffer + 1, buflen - 1); + app->app_local->keyattr[keyno].ecdh.hashalgo = buffer[1]; + app->app_local->keyattr[keyno].ecdh.cipheralgo = buffer[2]; } else if (opt.verbose) log_printhex ("", buffer, buflen); -- From gniibe at fsij.org Fri Mar 8 07:48:31 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 Mar 2013 15:48:31 +0900 Subject: scd: ECDSA sign support Message-ID: <1362725311.2667.3.camel@cfw2.gniibe.org> Here is another patch for GnuPG in the smartcard ECDSA support series. (There will be one more: support writekey for ECDSA.) This patch is to support ECDSA signing. This patch is made so that the change can be minimum. But it shows we would need to change the protocol between GPG-agent and SCDaemon. Currently, it's only for RSA and it supports multiple hash algorithms. GPG-agent encodes the hash algorithm block and prepend it to the data. For ECDSA, hash algorithm is implicitly determined by its key size, and we don't prepend the hash algorithm block. Thus, we just drop off the block added by GPG-agent. In the current implementation, do_sign checks hash algorithm. It remove off the hash algorithm block and put it again. I think that this check is not needed at SCDaemon. If it is OK to remove the checking of hash algorithm by SCDaemon, I'd like to remove it, and also remove adding the hash algorithm block for ECDSA by GPG-daemon. I'd like to change the code, step by step. I'll commit this change if there are no objections at first. Then, in the next step, I will change the protocol (we won't prepend hash algorithm block for ECDSA). I mean, change agent/divert-scd.c and scd/app-openpgp.c. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 8d507c4..1df35b2 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -3416,14 +3416,23 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, memcpy (data + sizeof b ## _prefix, indata, indatalen); \ } - X(SHA1, sha1, 1) - else X(RMD160, rmd160, 1) - else X(SHA224, sha224, app->app_local->extcap.is_v2) - else X(SHA256, sha256, app->app_local->extcap.is_v2) - else X(SHA384, sha384, app->app_local->extcap.is_v2) - else X(SHA512, sha512, app->app_local->extcap.is_v2) + if (use_auth + || app->app_local->keyattr[use_auth? 2: 0].key_type == KEY_TYPE_RSA) + { + X(SHA1, sha1, 1) + else X(RMD160, rmd160, 1) + else X(SHA224, sha224, app->app_local->extcap.is_v2) + else X(SHA256, sha256, app->app_local->extcap.is_v2) + else X(SHA384, sha384, app->app_local->extcap.is_v2) + else X(SHA512, sha512, app->app_local->extcap.is_v2) + else + return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); + } else - return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); + { + datalen = indatalen; + memcpy (data, indata, indatalen); + } #undef X /* Redirect to the AUTH command if asked to. */ @@ -3515,6 +3524,14 @@ do_auth (app_t app, const char *keyidstr, if (indatalen > 101) /* For a 2048 bit key. */ return gpg_error (GPG_ERR_INV_VALUE); + if (app->app_local->keyattr[2].key_type == KEY_TYPE_ECDSA + && (indatalen == 51 || indatalen == 67 || indatalen == 83) + { + const char *p = (const char *)indata + 19; + indata = p; + indatalen -= 19; + } + /* Check whether an OpenPGP card of any version has been requested. */ if (!strcmp (keyidstr, "OPENPGP.3")) ; -- From gniibe at fsij.org Sat Mar 9 01:58:22 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 09 Mar 2013 09:58:22 +0900 Subject: OpenPGP card specification enhancement for ECDSA support: key import Message-ID: <1362790702.2671.3.camel@cfw2.gniibe.org> Hello, For ECDSA/ECDH key import support, we need to update OpenPGP card specification. The section, 4.3.3.7 Private Key Template, is needed to modify. Currently, it defines RSA format. It will be something like: 9x xx ECDSA/ECDH secret key We could also include OID (and KDF parameters: hash function ID and algorithm ID for ECDS), but those are redundant. The first byte is 91? Or what value we use? The format of secret key is MPI of an integer representing the secret key. For your reference, in the section of "9. Encoding of Public and Private Keys" of RFC6637, it is described as: ------------------ The following algorithm-specific packets are added to Section 5.5.3. of [RFC4880], "Secret-Key Packet Formats", to support ECDH and ECDSA. Algorithm-Specific Fields for ECDH or ECDSA secret keys: o an MPI of an integer representing the secret key, which is a scalar of the public EC point ------------------ -- From x-alina at gmx.net Sun Mar 10 13:50:14 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Sun, 10 Mar 2013 13:50:14 +0100 (CET) Subject: Aw: Re: Pinpad support for REINER SCT cyberJack go In-Reply-To: <1362550466.6013.0.camel@cfw2.gniibe.org> References: <20130306032450.237000@gmx.net>, <1362550466.6013.0.camel@cfw2.gniibe.org> Message-ID: With both ways the pinpad does not work. I could only test the --card-edit commands. Importing my GnuPG-Card into the secret key ring does not work. So I can't test decryption and signing. Any ideas? > Gesendet: Mittwoch, 06. M?rz 2013 um 07:14 Uhr > Von: "NIIBE Yutaka" > An: "Alina Friedrichsen" > Cc: gnupg-devel at gnupg.org > Betreff: Re: Pinpad support for REINER SCT cyberJack go > > On 2013-03-06 at 04:24 +0100, Alina Friedrichsen wrote: > > I use GnuPG 2.0.19, build from source. > > In 2.0.19. pinpad input is not supported through PC/SC. > > The pinpad input feature for PC/SC has been added both of master and > STABLE-BRANCH-2.0. You will be able to use it with forthcoming > 2.0.20. (You will need to add enable-pinpad-varlen option for > ./gnupg/scdaemon.conf.) > > > lsusb: > > ID 0c4b:0504 Reiner SCT Kartensysteme GmbH > > > > gpg2: > > gpg: detected reader `REINER SCT cyberJack go (4603989351) 00 00' > > I got a report that following card reader works fine: > > 0c4b:0500 Reiner SCT Kartensysteme GmbH > "REINER SCT cyberJack RFID standard (7592671050) 00 00" > > Since it seems that your reader is newer than that, I hope that it > works well, too. > > Besides, for both of master and STABLE-BRANCH-2.0, internal CCID > driver got improved. I think that you can use your reader without > PC/SC. If it works, it is better for your reader to be added > to good readers list of enable_varlen=1 in scd/ccid-driver.c > so that you don't need to configure. > > If you have enough time, please try STABLE-BRANCH-2.0 of > git.gnupg.org. Or else, please wait for 2.0.20. > -- > > > From x-alina at gmx.net Sun Mar 10 14:32:38 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Sun, 10 Mar 2013 14:32:38 +0100 (CET) Subject: CHERRY SmartTerminal ST-2000UC-R Message-ID: Is this reader supported by GnuPG with pinpad support? http://www.ebay.de/itm/190532549287 Or what card reader do you recommend? From x-alina at gmx.net Sun Mar 10 19:30:48 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Sun, 10 Mar 2013 19:30:48 +0100 (CET) Subject: Aw: Re: Pinpad support for REINER SCT cyberJack go Message-ID: I build a zombie version GnuPG 2.0.19 with the scdaemon from the stable git. And yes, I can confirm signing with pinpad doesn't work with this reader, too. > Gesendet: Sonntag, 10. M?rz 2013 um 13:50 Uhr > Von: "Alina Friedrichsen" > An: "NIIBE Yutaka" > Cc: gnupg-devel at gnupg.org > Betreff: Aw: Re: Pinpad support for REINER SCT cyberJack go > > With both ways the pinpad does not work. > > I could only test the --card-edit commands. > Importing my GnuPG-Card into the secret key ring does not work. > So I can't test decryption and signing. > > Any ideas? > > > Gesendet: Mittwoch, 06. M?rz 2013 um 07:14 Uhr > > Von: "NIIBE Yutaka" > > An: "Alina Friedrichsen" > > Cc: gnupg-devel at gnupg.org > > Betreff: Re: Pinpad support for REINER SCT cyberJack go > > > > On 2013-03-06 at 04:24 +0100, Alina Friedrichsen wrote: > > > I use GnuPG 2.0.19, build from source. > > > > In 2.0.19. pinpad input is not supported through PC/SC. > > > > The pinpad input feature for PC/SC has been added both of master and > > STABLE-BRANCH-2.0. You will be able to use it with forthcoming > > 2.0.20. (You will need to add enable-pinpad-varlen option for > > ./gnupg/scdaemon.conf.) > > > > > lsusb: > > > ID 0c4b:0504 Reiner SCT Kartensysteme GmbH > > > > > > gpg2: > > > gpg: detected reader `REINER SCT cyberJack go (4603989351) 00 00' > > > > I got a report that following card reader works fine: > > > > 0c4b:0500 Reiner SCT Kartensysteme GmbH > > "REINER SCT cyberJack RFID standard (7592671050) 00 00" > > > > Since it seems that your reader is newer than that, I hope that it > > works well, too. > > > > Besides, for both of master and STABLE-BRANCH-2.0, internal CCID > > driver got improved. I think that you can use your reader without > > PC/SC. If it works, it is better for your reader to be added > > to good readers list of enable_varlen=1 in scd/ccid-driver.c > > so that you don't need to configure. > > > > If you have enough time, please try STABLE-BRANCH-2.0 of > > git.gnupg.org. Or else, please wait for 2.0.20. > > -- > > > > > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From gniibe at fsij.org Mon Mar 11 00:59:53 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Mar 2013 08:59:53 +0900 Subject: Aw: Re: Pinpad support for REINER SCT cyberJack go In-Reply-To: References: Message-ID: <1362959993.2663.2.camel@cfw2.gniibe.org> Hello, On 2013-03-10 at 19:30 +0100, Alina Friedrichsen wrote: > I build a zombie version GnuPG 2.0.19 with the scdaemon from the stable git. I'm sorry, I can't understand what this means and/or what you intend to do that. > And yes, I can confirm signing with pinpad doesn't work with this reader, too. Thanks. But, it is difficult for me to do some useful work, given this information. Could you please follow proper steps to build, install, and test? Your cooperation is needed, here. If it is difficult for you, please just wait 2.0.20. If you want, please get STABLE-BRANCH-2-0 branch from the Git repository, and build and install following README.GIT. Testing another version, it is better to do: (1) Make temporary working directory. Such as: /var/tmp/gpg-test. (2) Make a file for Scdaemon configuration, with the content: ---------------------------- /var/tmp/ggp-test/scdaemon.conf debug-level guru debug-all log-file /var/tmp/scd.log debug-ccid-driver ---------------------------- (3) Run GPG-agent in terminal: $ gpg-agent --homedir=/var/tmp/gpg-test --daemon /bin/bash Then, use this shell session for your test. $ gpg2 --card-status $ gpg2 --card-edit (3-1) Run "verify" in the session of --card-edit (3-2) Run "passwd" in the session of --card-edit (3-3) Become Admin and do key generation in the session of --card-edit (3-4) Exit from the session of --card-edit (3-5) Do signing, etc. -- From gniibe at fsij.org Mon Mar 11 01:08:57 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Mar 2013 09:08:57 +0900 Subject: CHERRY SmartTerminal ST-2000UC-R In-Reply-To: References: Message-ID: <1362960537.2663.4.camel@cfw2.gniibe.org> On 2013-03-10 at 14:32 +0100, Alina Friedrichsen wrote: > Or what card reader do you recommend? It depends on your purpose and situation. I have two pinpad readers which works with GnuPG: Gemalto GemPC Pinpad Vasco DIGIPASS 920 Gemalto GemPC Pinpad doesn't support variable length pinpad input, so we need some configuration for GnuPG and we need to put some information on the card. Vasco DIGIPASS 920 supports variable length pinpad input, it's good. But it has a feature of "firewall", and it doesn't allow usual "VERIFY" command at all, but only allows authentication by its pinpad. This would not be good for some cases. And availability of this card reader would not be good. -- From x-alina at gmx.net Mon Mar 11 12:15:01 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Mon, 11 Mar 2013 12:15:01 +0100 (CET) Subject: Aw: Re: Re: Pinpad support for REINER SCT cyberJack go Message-ID: Hallo! > > I build a zombie version GnuPG 2.0.19 with the scdaemon from the stable git. > > I'm sorry, I can't understand what this means and/or what you intend > to do that. Running GnuPG 2.0.19 with the scdaemon from the stable git. > > And yes, I can confirm signing with pinpad doesn't work with this reader, too. > > Thanks. But, it is difficult for me to do some useful work, given > this information. > > Could you please follow proper steps to build, install, and test? > Your cooperation is needed, here. > > If it is difficult for you, please just wait 2.0.20. > > If you want, please get STABLE-BRANCH-2-0 branch from the Git > repository, and build and install following README.GIT. > > Testing another version, it is better to do: > > (1) Make temporary working directory. Such as: /var/tmp/gpg-test. > (2) Make a file for Scdaemon configuration, with the content: I use the internal CCID driver now. > ---------------------------- /var/tmp/ggp-test/scdaemon.conf > debug-level guru > debug-all > log-file /var/tmp/scd.log > debug-ccid-driver > ---------------------------- > > (3) Run GPG-agent in terminal: > > $ gpg-agent --homedir=/var/tmp/gpg-test --daemon /bin/bash > > Then, use this shell session for your test. > > $ gpg2 --card-status > $ gpg2 --card-edit > > (3-1) Run "verify" in the session of --card-edit pinentry say I should enter the PIN on the Pinpad, but the pinpad don't react. It still shows the home screen. > > (3-2) Run "passwd" in the session of --card-edit The same. > (3-3) Become Admin and do key generation in the session of --card-edit > > (3-4) Exit from the session of --card-edit > > (3-5) Do signing, etc. I can't do that. I have only one GnuPG card and I need the keys on it. Regards, Alina From christian at quelltextlich.at Mon Mar 11 13:19:11 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Mon, 11 Mar 2013 13:19:11 +0100 Subject: Pinpad smartcard readers with pinpad support in released GnuPG versions [was: Re: CHERRY SmartTerminal ST-2000UC-R] In-Reply-To: References: Message-ID: <20130311121911.GA32079@quelltextlich.at> Hi Alina, On Sun, Mar 10, 2013 at 02:32:38PM +0100, Alina Friedrichsen wrote: > Is this reader supported by GnuPG with pinpad support? > [...] > > Or what card reader do you recommend? If you're looking for a pinpad card reader whose pinpad is supported in a /released/ GnuPG, I'd go for the SCM SPR-332. http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=61 . The reader works like a charm for me, and GnuPG 2.0.19 supports the reader's pinpad through GnuPGs internal driver out-of-the box. Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Mon Mar 11 13:28:02 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Mon, 11 Mar 2013 13:28:02 +0100 Subject: CHERRY SmartTerminal ST-2000UC-R In-Reply-To: <1362960537.2663.4.camel@cfw2.gniibe.org> References: <1362960537.2663.4.camel@cfw2.gniibe.org> Message-ID: <20130311122801.GB32079@quelltextlich.at> Hello, On Mon, Mar 11, 2013 at 09:08:57AM +0900, NIIBE Yutaka wrote: > [ Gemalto GemPC Pinpad ] just a word of warning: The improved support for this reader has only been merged to git recently. The currently latest GnuPG release 2.0.19 does not support the reader too well. Maybe it was just me failing, but I for one could not get the reader's pinpad to work with GnuPG 2.0.19. YMMV. Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From x-alina at gmx.net Mon Mar 11 13:54:47 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Mon, 11 Mar 2013 13:54:47 +0100 (CET) Subject: Add pinpad support for REINER SCT cyberJack go Message-ID: This patch adds pinpad support for the REINER SCT cyberJack go CCID reader. Please put it into stable. Much, much thanks to NIIBE Yutaka for helping debugging! Signed-off-by: Alina Friedrichsen --- diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 2d1ef8d..f51299e 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -212,7 +212,8 @@ enum { VENDOR_VEGA = 0x0982, VENDOR_KAAN = 0x0d46, VENDOR_FSIJ = 0x234b, - VENDOR_VASCO = 0x1a44 + VENDOR_VASCO = 0x1a44, + VENDOR_REINER = 0x0c4b }; /* Some product ids. */ @@ -225,6 +226,7 @@ enum { #define VASCO_920 0x0920 #define GEMPC_PINPAD 0x3478 #define VEGA_ALPHA 0x0008 +#define CYBERJACK_GO 0x0504 /* A list and a table with special transport descriptions. */ enum { @@ -3390,6 +3392,11 @@ ccid_transceive_secure (ccid_driver_t handle, if (handle->id_product != CHERRY_ST2000) cherry_mode = 1; break; + case VENDOR_REINER: + if(handle->id_product == CYBERJACK_GO) + enable_varlen = 1; + pininfo->maxlen = 15; + break; default: if ((handle->id_vendor == VENDOR_GEMPC && handle->id_product == GEMPC_PINPAD) From x-alina at gmx.net Mon Mar 11 14:01:51 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Mon, 11 Mar 2013 14:01:51 +0100 (CET) Subject: [PATCH] Add pinpad support for REINER SCT cyberJack go Message-ID: This patch adds pinpad support for the REINER SCT cyberJack go CCID reader. Please put it into stable. Much, much thanks to NIIBE Yutaka for helping debugging! Signed-off-by: Alina Friedrichsen --- diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 2d1ef8d..f51299e 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -212,7 +212,8 @@ enum { VENDOR_VEGA = 0x0982, VENDOR_KAAN = 0x0d46, VENDOR_FSIJ = 0x234b, - VENDOR_VASCO = 0x1a44 + VENDOR_VASCO = 0x1a44, + VENDOR_REINER = 0x0c4b }; /* Some product ids. */ @@ -225,6 +226,7 @@ enum { #define VASCO_920 0x0920 #define GEMPC_PINPAD 0x3478 #define VEGA_ALPHA 0x0008 +#define CYBERJACK_GO 0x0504 /* A list and a table with special transport descriptions. */ enum { @@ -3390,6 +3392,11 @@ ccid_transceive_secure (ccid_driver_t handle, if (handle->id_product != CHERRY_ST2000) cherry_mode = 1; break; + case VENDOR_REINER: + if(handle->id_product == CYBERJACK_GO) + enable_varlen = 1; + pininfo->maxlen = 15; + break; default: if ((handle->id_vendor == VENDOR_GEMPC && handle->id_product == GEMPC_PINPAD) From gniibe at fsij.org Mon Mar 11 14:14:26 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Mar 2013 22:14:26 +0900 Subject: [PATCH] Add pinpad support for REINER SCT cyberJack go In-Reply-To: References: Message-ID: <1363007666.2540.3.camel@latx1.gniibe.org> IIUC, you need { and } here. On 2013-03-11 at 14:01 +0100, Alina Friedrichsen wrote: > @@ -3390,6 +3392,11 @@ ccid_transceive_secure (ccid_driver_t handle, > if (handle->id_product != CHERRY_ST2000) > cherry_mode = 1; > break; > + case VENDOR_REINER: > + if(handle->id_product == CYBERJACK_GO) { > + enable_varlen = 1; > + pininfo->maxlen = 15; } > + break; > default: > if ((handle->id_vendor == VENDOR_GEMPC && > handle->id_product == GEMPC_PINPAD) -- From x-alina at gmx.net Mon Mar 11 14:15:36 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Mon, 11 Mar 2013 14:15:36 +0100 (CET) Subject: Now I have only one problem Message-ID: The stable GnuPG from git do not read my secring.gpg from GnuPG 1.4.12, so I can't sign and decrypt. GnuPG 2.0.19 works fine. Is there a way to fix this, or must I backport the CCID stuff to GnuPG 2.0.19? Regards, Alina From x-alina at gmx.net Mon Mar 11 14:26:36 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Mon, 11 Mar 2013 14:26:36 +0100 (CET) Subject: [PATCH v2] Add pinpad support for REINER SCT cyberJack go Message-ID: This patch adds pinpad support for the REINER SCT cyberJack go CCID reader. Please put it into stable. Much, much thanks to NIIBE Yutaka for helping debugging and bugfixing my oversight! Signed-off-by: Alina Friedrichsen --- diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 2d1ef8d..359f8e0 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -212,7 +212,8 @@ enum { VENDOR_VEGA = 0x0982, VENDOR_KAAN = 0x0d46, VENDOR_FSIJ = 0x234b, - VENDOR_VASCO = 0x1a44 + VENDOR_VASCO = 0x1a44, + VENDOR_REINER = 0x0c4b }; /* Some product ids. */ @@ -225,6 +226,7 @@ enum { #define VASCO_920 0x0920 #define GEMPC_PINPAD 0x3478 #define VEGA_ALPHA 0x0008 +#define CYBERJACK_GO 0x0504 /* A list and a table with special transport descriptions. */ enum { @@ -3390,6 +3392,13 @@ ccid_transceive_secure (ccid_driver_t handle, if (handle->id_product != CHERRY_ST2000) cherry_mode = 1; break; + case VENDOR_REINER: + if (handle->id_product == CYBERJACK_GO) + { + enable_varlen = 1; + pininfo->maxlen = 15; + } + break; default: if ((handle->id_vendor == VENDOR_GEMPC && handle->id_product == GEMPC_PINPAD) From wk at gnupg.org Mon Mar 11 16:04:45 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Mar 2013 16:04:45 +0100 Subject: Now I have only one problem In-Reply-To: (Alina Friedrichsen's message of "Mon, 11 Mar 2013 14:15:36 +0100 (CET)") References: Message-ID: <871ubm6kqa.fsf@vigenere.g10code.de> On Mon, 11 Mar 2013 14:15, x-alina at gmx.net said: > The stable GnuPG from git do not read my secring.gpg from GnuPG > 1.4.12, so I can't sign and decrypt. GnuPG 2.0.19 works fine. Is there You used STABLE-BRANCH-2-0, right? Git master does not anymore use secring.gpg. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Mon Mar 11 23:19:22 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Mon, 11 Mar 2013 23:19:22 +0100 (CET) Subject: Aw: Re: Now I have only one problem Message-ID: Hallo Werner! > You used STABLE-BRANCH-2-0, right? Yes. > Git master does not anymore use > secring.gpg. STABLE-BRANCH-2-0 has the same Problem. How can I import my existing GnuPG smart card? Regards, Alina From gniibe at fsij.org Tue Mar 12 00:47:37 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Mar 2013 08:47:37 +0900 Subject: Aw: Re: Now I have only one problem In-Reply-To: References: Message-ID: <1363045657.2810.2.camel@cfw2.gniibe.org> On 2013-03-11 at 23:19 +0100, Alina Friedrichsen wrote: > How can I import my existing GnuPG smart card? Please elaborate your problem. I think that the change of GnuPG in STABLE-BRANCH-2-0 is not that big since 2.0.19, but most changes are for SCDaemon. There are gpg, gpg-agent, and scdaemon (I attached a figure. It's for Gnuk Token, please read as it's your card reader + OpenPGP card). (1) Does GnuPG STABLE-BRANCH-2-0 work well standalone for signing when not using OpenPGP card? (1-1) How about GnuPG 1.4.13, when (1) is NO? (2) Is it a failure when you did "gpg --edit-key" and "keytocard"? (3) Or else, is it a failure when you did try to sign with the card? -- -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-agent-scdaemon.png Type: image/png Size: 19227 bytes Desc: not available URL: From gniibe at fsij.org Tue Mar 12 09:19:26 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Mar 2013 17:19:26 +0900 Subject: [PATCH] agent and scd: Don't prepend message digest Message-ID: <1363076366.12571.4.camel@cfw2.gniibe.org> Hello, This patch is to simplify code of GPG-Agent and SCDaemon for signing/authentication. Currently, we always prepend message digest specifier and it is checked by SCDaemon. With this patch, it will be only prepended for RSA and not for ECDSA, and it will be not checked by SCDaemon. This patch changes the protocol between GPG-Agent and SCDaemon for ECDSA signing/authentication. It doesn't change for RSA case. I think that removal of the check by SCDaemon is no problem. Please correct me if I'm wrong. I will commit this if there is no problem. diff --git a/agent/agent.h b/agent/agent.h index 2fd0b8b..28f69f5 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -403,7 +403,7 @@ void agent_reload_trustlist (void); /*-- divert-scd.c --*/ -int divert_pksign (ctrl_t ctrl, +int divert_pksign (ctrl_t ctrl, int add_md, const unsigned char *digest, size_t digestlen, int algo, const unsigned char *shadow_info, unsigned char **r_sig, size_t *r_siglen); diff --git a/agent/divert-scd.c b/agent/divert-scd.c index f0d8473..38fab0e 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -333,7 +333,7 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) int -divert_pksign (ctrl_t ctrl, +divert_pksign (ctrl_t ctrl, int add_md, const unsigned char *digest, size_t digestlen, int algo, const unsigned char *shadow_info, unsigned char **r_sig, size_t *r_siglen) @@ -360,13 +360,19 @@ divert_pksign (ctrl_t ctrl, unsigned char *data; size_t ndata; - rc = encode_md_for_card (digest, digestlen, algo, &data, &ndata); - if (!rc) + if (add_md) { - rc = agent_card_pksign (ctrl, kid, getpin_cb, ctrl, - algo, data, ndata, &sigval, &siglen); - xfree (data); + rc = encode_md_for_card (digest, digestlen, algo, &data, &ndata); + if (!rc) + { + rc = agent_card_pksign (ctrl, kid, getpin_cb, ctrl, + algo, data, ndata, &sigval, &siglen); + xfree (data); + } } + else + rc = agent_card_pksign (ctrl, kid, getpin_cb, ctrl, + algo, digest, digestlen, &sigval, &siglen); } if (!rc) diff --git a/agent/pksign.c b/agent/pksign.c index 8518730..5646d1c 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -301,7 +301,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, gcry_sexp_release (l); gcry_sexp_release (s_pkey); - rc = divert_pksign (ctrl, + rc = divert_pksign (ctrl, is_RSA, ctrl->digest.value, ctrl->digest.valuelen, ctrl->digest.algo, diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 1df35b2..d2d33c3 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -3299,31 +3299,7 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, const void *indata, size_t indatalen, unsigned char **outdata, size_t *outdatalen ) { - static unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ - { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x24, 0x03, - 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char sha1_prefix[15] = /* (1.3.14.3.2.26) */ - { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, - 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char sha224_prefix[19] = /* (2.16.840.1.101.3.4.2.4) */ - { 0x30, 0x2D, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, - 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, - 0x1C }; - static unsigned char sha256_prefix[19] = /* (2.16.840.1.101.3.4.2.1) */ - { 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, - 0x00, 0x04, 0x20 }; - static unsigned char sha384_prefix[19] = /* (2.16.840.1.101.3.4.2.2) */ - { 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, - 0x00, 0x04, 0x30 }; - static unsigned char sha512_prefix[19] = /* (2.16.840.1.101.3.4.2.3) */ - { 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, - 0x00, 0x04, 0x40 }; int rc; - unsigned char data[19+64]; - size_t datalen; unsigned char tmp_sn[20]; /* Actually 16 bytes but also for the fpr. */ const char *s; int n; @@ -3335,38 +3311,6 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, if (!keyidstr || !*keyidstr) return gpg_error (GPG_ERR_INV_VALUE); - /* Strip off known prefixes. */ -#define X(a,b,c,d) \ - if (hashalgo == GCRY_MD_ ## a \ - && (d) \ - && indatalen == sizeof b ## _prefix + (c) \ - && !memcmp (indata, b ## _prefix, sizeof b ## _prefix)) \ - { \ - indata = (const char*)indata + sizeof b ## _prefix; \ - indatalen -= sizeof b ## _prefix; \ - } - - if (indatalen == 20) - ; /* Assume a plain SHA-1 or RMD160 digest has been given. */ - else X(SHA1, sha1, 20, 1) - else X(RMD160, rmd160, 20, 1) - else X(SHA224, sha224, 28, app->app_local->extcap.is_v2) - else X(SHA256, sha256, 32, app->app_local->extcap.is_v2) - else X(SHA384, sha384, 48, app->app_local->extcap.is_v2) - else X(SHA512, sha512, 64, app->app_local->extcap.is_v2) - else if ((indatalen == 28 || indatalen == 32 - || indatalen == 48 || indatalen ==64) - && app->app_local->extcap.is_v2) - ; /* Assume a plain SHA-3 digest has been given. */ - else - { - log_error (_("card does not support digest algorithm %s\n"), - gcry_md_algo_name (hashalgo)); - /* Or the supplied digest length does not match an algorithm. */ - return gpg_error (GPG_ERR_INV_VALUE); - } -#undef X - /* Check whether an OpenPGP card of any version has been requested. */ if (!strcmp (keyidstr, "OPENPGP.1")) ; @@ -3406,40 +3350,11 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, if (rc) return rc; - /* Concatenate prefix and digest. */ -#define X(a,b,d) \ - if (hashalgo == GCRY_MD_ ## a && (d) ) \ - { \ - datalen = sizeof b ## _prefix + indatalen; \ - assert (datalen <= sizeof data); \ - memcpy (data, b ## _prefix, sizeof b ## _prefix); \ - memcpy (data + sizeof b ## _prefix, indata, indatalen); \ - } - - if (use_auth - || app->app_local->keyattr[use_auth? 2: 0].key_type == KEY_TYPE_RSA) - { - X(SHA1, sha1, 1) - else X(RMD160, rmd160, 1) - else X(SHA224, sha224, app->app_local->extcap.is_v2) - else X(SHA256, sha256, app->app_local->extcap.is_v2) - else X(SHA384, sha384, app->app_local->extcap.is_v2) - else X(SHA512, sha512, app->app_local->extcap.is_v2) - else - return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); - } - else - { - datalen = indatalen; - memcpy (data, indata, indatalen); - } -#undef X - /* Redirect to the AUTH command if asked to. */ if (use_auth) { return do_auth (app, "OPENPGP.3", pincb, pincb_arg, - data, datalen, + indata, indatalen, outdata, outdatalen); } @@ -3491,7 +3406,7 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, exmode = 0; le_value = 0; } - rc = iso7816_compute_ds (app->slot, exmode, data, datalen, le_value, + rc = iso7816_compute_ds (app->slot, exmode, indata, indatalen, le_value, outdata, outdatalen); return rc; } @@ -3524,14 +3439,6 @@ do_auth (app_t app, const char *keyidstr, if (indatalen > 101) /* For a 2048 bit key. */ return gpg_error (GPG_ERR_INV_VALUE); - if (app->app_local->keyattr[2].key_type == KEY_TYPE_ECDSA - && (indatalen == 51 || indatalen == 67 || indatalen == 83) - { - const char *p = (const char *)indata + 19; - indata = p; - indatalen -= 19; - } - /* Check whether an OpenPGP card of any version has been requested. */ if (!strcmp (keyidstr, "OPENPGP.3")) ; -- From x-alina at gmx.net Tue Mar 12 10:47:53 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Tue, 12 Mar 2013 10:47:53 +0100 Subject: Now I have only one problem In-Reply-To: <1363045657.2810.2.camel@cfw2.gniibe.org> References: <1363045657.2810.2.camel@cfw2.gniibe.org> Message-ID: <1363081673.4172.6.camel@e525.x-alina.name> I have recompiled STABLE-BRANCH-2-0 and all the other stuff. I created new keys. Now I can sign, but not decrypt with the internal CCID driver. If I use pcscd and not the internal driver decryption works. Regards, Alina From x-alina at gmx.net Tue Mar 12 14:33:05 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Tue, 12 Mar 2013 14:33:05 +0100 (CET) Subject: Now I have only one problem In-Reply-To: <1363094416.1878.2.camel@latx1.gniibe.org> References: <1363045657.2810.2.camel@cfw2.gniibe.org> <1363081673.4172.6.camel@e525.x-alina.name>, <1363094416.1878.2.camel@latx1.gniibe.org> Message-ID: > Is your key 4096-bit? No, 3072 bit. > Please try following patch. Okay. From gniibe at fsij.org Tue Mar 12 14:20:16 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Mar 2013 22:20:16 +0900 Subject: Now I have only one problem In-Reply-To: <1363081673.4172.6.camel@e525.x-alina.name> References: <1363045657.2810.2.camel@cfw2.gniibe.org> <1363081673.4172.6.camel@e525.x-alina.name> Message-ID: <1363094416.1878.2.camel@latx1.gniibe.org> On 2013-03-12 at 10:47 +0100, Alina Friedrichsen wrote: > I have recompiled STABLE-BRANCH-2-0 and all the other stuff. > I created new keys. > > Now I can sign, but not decrypt with the internal CCID driver. > If I use pcscd and not the internal driver decryption works. Is your key 4096-bit? Please try following patch. diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index ccf579c..dd9fabe 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -2840,7 +2840,7 @@ ccid_transceive_apdu_level (ccid_driver_t handle, /* The maximum length for a short APDU T=1 block is 261. For an extended APDU T=1 block the maximum length 65544; however extended APDU exchange level is not fully supported yet. */ - if (apdulen > 289) + if (apdulen > sizeof (send_buffer) - 10) return CCID_DRIVER_ERR_INV_VALUE; /* Invalid length. */ msg[0] = PC_to_RDR_XfrBlock; -- From x-alina at gmx.net Tue Mar 12 15:40:49 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Tue, 12 Mar 2013 15:40:49 +0100 Subject: [PATCH v2] Add pinpad support for REINER SCT cyberJack go In-Reply-To: References: Message-ID: <1363099249.4129.5.camel@e525.x-alina.name> What must I test to get this patch together with the last patch from NIIBE Yutaka into STABLE-BRANCH-2-0? Am Montag, den 11.03.2013, 14:26 +0100 schrieb Alina Friedrichsen: > This patch adds pinpad support for the REINER SCT cyberJack go CCID reader. > Please put it into stable. > > Much, much thanks to NIIBE Yutaka for helping debugging > and bugfixing my oversight! > > Signed-off-by: Alina Friedrichsen From wk at gnupg.org Tue Mar 12 15:37:09 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Mar 2013 15:37:09 +0100 Subject: [PATCH] agent and scd: Don't prepend message digest In-Reply-To: <1363076366.12571.4.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 12 Mar 2013 17:19:26 +0900") References: <1363076366.12571.4.camel@cfw2.gniibe.org> Message-ID: <874ngg65wq.fsf@vigenere.g10code.de> On Tue, 12 Mar 2013 09:19, gniibe at fsij.org said: > signing/authentication. Currently, we always prepend message digest > specifier and it is checked by SCDaemon. With this patch, it will be > only prepended for RSA and not for ECDSA, and it will be not checked Looking at the patch I can't see who this is only used for ECDSA. You remove the entire prefixing from do_sign. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Tue Mar 12 15:43:00 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Tue, 12 Mar 2013 15:43:00 +0100 (CET) Subject: Now I have only one problem Message-ID: > Please try following patch. Thank you, it works! :) How can I use the internal CCID driver as user? Currently I do all as root. Alina From dkg at fifthhorseman.net Tue Mar 12 21:51:20 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 Mar 2013 16:51:20 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation Message-ID: <87obeo2vg7.fsf@alice.fifthhorseman.net> following a discussion on the IETF mailing list [0], i did a couple of experiments with GnuPG, to see if i could make a subkey with the usage flags subpacket set to an all-zero byte, or with a critical notation. (this would allow specific alternate uses to be identified with notation subpackets without needing to navigate the WG resistance against expanding the usage flag bits) Below is an example OpenPGP key with three subkeys: * the first (1024bit DSA) is marked authentication-capable, with a critical notation that gpg doesn't know about. gpg marks this with usage flags "a", depsite the critical notation. should this subkey binding signature be acceptable to gpg even in the face of the critical notation? * the second (512bit DSA) has no usage flags subpacket at all in the binding signature. gpg marks this "sca", presumably because those are all the capabilities supported by DSA. * the third (768bit DSA) has a usage flags subpacket with all bits set to zero. gpg marks this also as "sca". -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: example.key URL: -------------- next part -------------- To generate the second subkey, I used: gpg --expert --edit-key "$test_uid" addkey and toggled off all the flags for the subkey. As you can see, the resultant key had no usage flags subpacket at all, which led GnuPG to interpret it as "any usage allowed" (sca, in the case of a DSA key, since DSA can't be used for encryption). To generate the third subkey binding signature, i had to modify do_add_key_flags() in g10/keygen.c, since it currently declines to add a usage flags subpacket if all bits are off. I think GnuPG's handling of (at least) the third subkey is buggy, and potentially dangerously so -- for example, if the "certify" bit is present and set to 0, GnuPG should not accept a certification made from the given subkey. The attached patch (against 1.4.12) seems to work to permit the creation of an all-empty set of usage flags: -------------- next part -------------- A non-text attachment was scrubbed... Name: allow-empty-usage-flags.patch Type: text/x-diff Size: 291 bytes Desc: allow empty usage flags URL: -------------- next part -------------- It looks to me like this code can only be reached via --expert mode anyway, since otherwise there is no way to turn off all the usage flag bits through the UI. So i think we need to think through a few questions: * what should GnuPG do when presented with a subkey binding signatures with critical subpackets that it does not understand? * what should GnuPG do when presented with a subkey binding signature with an all-zero usage flags subpacket? * (less importantly) should GnuPG be able to generate such a subkey binding signature? Any suggestions or proposals? Regards, --dkg [0] http://thread.gmane.org/gmane.ietf.openpgp/7333 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From gniibe at fsij.org Wed Mar 13 02:05:21 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Mar 2013 10:05:21 +0900 Subject: [PATCH] agent and scd: Don't prepend message digest In-Reply-To: <874ngg65wq.fsf@vigenere.g10code.de> References: <1363076366.12571.4.camel@cfw2.gniibe.org> <874ngg65wq.fsf@vigenere.g10code.de> Message-ID: <1363136721.2682.2.camel@cfw2.gniibe.org> On 2013-03-12 at 15:37 +0100, Werner Koch wrote: > On Tue, 12 Mar 2013 09:19, gniibe at fsij.org said: > > > signing/authentication. Currently, we always prepend message digest > > specifier and it is checked by SCDaemon. With this patch, it will be > > only prepended for RSA and not for ECDSA, and it will be not checked > > Looking at the patch I can't see who this is only used for ECDSA. You > remove the entire prefixing from do_sign. I'm sorry, my explanation was not good enough. Let me rephrase. When signing, GPG-Agent prepend message digest specifier (the prefix) always. The call chain in question is: divert-scd.c:divert_pksign -> call-scd.c:agent_card_pksign Here, encode_md_for_card is called before calling agent_card_pksign to add the prefix. There is another flow (algo == MD_USER_TLS_MD5SHA1), which doesn't call encode_md_for_card, but this case is: ctrl->use_auth_call = 1, which results PKAUTH (not PKSIGN) in agent_card_pksign. My change will remove this prefixing for ECDSA, but keep it for RSA. Please note that the prefix is always available for RSA for PKSIGN. I assume that the only client of SCDaemon is GPG-Agent of the same version (or a bit old versions, but not all of past versions). I think that it is OK to ignore other clients or very old versions. <--- I didn't say this in the previous message. At SCDaemon side, it examines the prefix while removing off it (the first X) if any, and adds again (the second X). My change will remove this processing entirely: no checking, no removing, and no adding. This change is *not* 100% compatible, it won't work with a digest with no prefix for RSA. In the case of no prefix (plain SHA1 or RMD160), current code adds relevant prefix in do_sign, while code with my change will cause an error. I think that there will be no problem, however, because there is always the prefix for RSA (for recent GPG-Agent). -- From gniibe at fsij.org Wed Mar 13 02:31:36 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Mar 2013 10:31:36 +0900 Subject: Now I have only one problem In-Reply-To: References: Message-ID: <1363138296.2682.3.camel@cfw2.gniibe.org> On 2013-03-12 at 15:43 +0100, Alina Friedrichsen wrote: > Thank you, it works! :) Good! > How can I use the internal CCID driver as user? > Currently I do all as root. If you are using Debian, it's like: Create a file something like /etc/udev/rules.d/60-gnupg-scdaemon-usb.rules, with the content of: -------------- SUBSYSTEMS=="usb", ATTRS{idVendor}=="0c4b", ATTRS{idProduct}=="0504", \ ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg" -------------- This is to add UDEV rules. If your are using other GNU/Linux, something similar is needed. I think that this kind of configuration should be handled by GnuPG / SCDaemon package in distribution(s). [1] Reference: [1] http://wiki.debian.org/GnuPG/CCID_Driver -- From x-alina at gmx.net Wed Mar 13 03:00:36 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 13 Mar 2013 03:00:36 +0100 Subject: Now I have only one problem In-Reply-To: <1363138296.2682.3.camel@cfw2.gniibe.org> References: <1363138296.2682.3.camel@cfw2.gniibe.org> Message-ID: <1363140036.4129.32.camel@e525.x-alina.name> > > Thank you, it works! :) > > Good! Changing key works, too. While changing my Admin-PIN I must done a mistaken, so I have killed my card. :( From gniibe at fsij.org Wed Mar 13 03:27:49 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Mar 2013 11:27:49 +0900 Subject: Now I have only one problem In-Reply-To: <1363140036.4129.32.camel@e525.x-alina.name> References: <1363138296.2682.3.camel@cfw2.gniibe.org> <1363140036.4129.32.camel@e525.x-alina.name> Message-ID: <1363141669.2682.6.camel@cfw2.gniibe.org> On 2013-03-13 at 03:00 +0100, Alina Friedrichsen wrote: > Changing key works, too. > While changing my Admin-PIN I must done a mistaken, > so I have killed my card. :( There is a reset procedure for OpenPGP card. I found a script by Werner Koch, in the gnupg-users archive: http://lists.gnupg.org/pipermail/gnupg-users/2013-March/046261.html Save the content to a file (the first line of "/hex" and the last line of "/echo ..."), say, openpgp-reset.txt, and invoke gpg-connect-agent: $ gpg-connect-agent --run openpgp-reset.txt /bye If this works, you can use the card again. -- From x-alina at gmx.net Wed Mar 13 04:53:14 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 13 Mar 2013 04:53:14 +0100 (CET) Subject: Now I have only one problem Message-ID: Now the card is completely death: root at e525:/home/x-alina# LANG=C gpg2 --card-status gpg: OpenPGP card not available: Not supported Am Mittwoch, den 13.03.2013, 11:27 +0900 schrieb NIIBE Yutaka: > On 2013-03-13 at 03:00 +0100, Alina Friedrichsen wrote: > > Changing key works, too. > > While changing my Admin-PIN I must done a mistaken, > > so I have killed my card. :( > > There is a reset procedure for OpenPGP card. I found a script by > Werner Koch, in the gnupg-users archive: > > http://lists.gnupg.org/pipermail/gnupg-users/2013-March/046261.html > > Save the content to a file (the first line of "/hex" and the last line > of "/echo ..."), say, openpgp-reset.txt, and invoke gpg-connect-agent: > > $ gpg-connect-agent --run openpgp-reset.txt /bye > > If this works, you can use the card again. From x-alina at gmx.net Wed Mar 13 05:28:01 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 13 Mar 2013 05:28:01 +0100 Subject: Now I have only one problem In-Reply-To: References: Message-ID: <1363148881.4193.9.camel@e525.x-alina.name> So, card death, reader waggly: I will send it back to factory. I hope my work was not useless and my and NIIBE Yutaka's patches go upstream into master and stable. I found no error with both patches, so I think they are stable. Regard, Alina From gniibe at fsij.org Wed Mar 13 07:00:05 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Mar 2013 15:00:05 +0900 Subject: Now I have only one problem In-Reply-To: <1363148881.4193.9.camel@e525.x-alina.name> References: <1363148881.4193.9.camel@e525.x-alina.name> Message-ID: <1363154405.23342.0.camel@cfw2.gniibe.org> On 2013-03-13 at 05:28 +0100, Alina Friedrichsen wrote: > So, card death, reader waggly: > I will send it back to factory. I'm very sorry. I did, and my card was also died (once). For my card, I managed to get its life back again with following script. $ python come-back-openpgpcard.py You need to install python-pyscard (this is package name in Debian), the PyScard library to use this. --------------------------- come-back-openpgpcard.py #! /usr/bin/python # Assume only single CCID device is attached to computer with card from smartcard.CardType import AnyCardType from smartcard.CardRequest import CardRequest from smartcard.util import toHexString class Card(object): def __init__(self): cardtype = AnyCardType() cardrequest = CardRequest(timeout=10, cardType=cardtype) cardservice = cardrequest.waitforcard() self.connection = cardservice.connection if __name__ == '__main__': card = Card() card.connection.connect() ident = card.connection.getReader() print "Reader:", ident print "ATR:", toHexString( card.connection.getATR() ) apdu = [ 0x00, 0xa4, 0x04, 0x00, 6, 0xd2, 0x76, 0x00, 0x01, 0x24, 0x01 ] response, sw1, sw2 = card.connection.transmit(apdu) print "%02x %02x %s" % (sw1, sw2, response) apdu = [ 0x00, 0x44, 0x00, 0x00 ] response, sw1, sw2 = card.connection.transmit(apdu) print "%02x %02x %s" % (sw1, sw2, response) card.connection.disconnect() -- From gniibe at fsij.org Wed Mar 13 07:07:00 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Mar 2013 15:07:00 +0900 Subject: Now I have only one problem In-Reply-To: <1363154405.23342.0.camel@cfw2.gniibe.org> References: <1363148881.4193.9.camel@e525.x-alina.name> <1363154405.23342.0.camel@cfw2.gniibe.org> Message-ID: <1363154820.23387.0.camel@cfw2.gniibe.org> I forgot to say that we need to activate PC/SC service to run the script. On 2013-03-13 at 15:00 +0900, NIIBE Yutaka wrote: > I'm very sorry. I did, and my card was also died (once). > > For my card, I managed to get its life back again with following script. > > $ python come-back-openpgpcard.py In my case, it's like this: ------------------------- $ python come-back-openpgpcard.py Reader: Gemalto USB GemPCPinpad SmartCard Reader 00 00 ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 62 85 [] 90 00 [] ------------------------- It fails to select OpenPGP application (6285: Selected file in termination state), but we proceed anyway to activate it, then it get success for that. After this, my card works again. I wish yours will, too. -- From christian at quelltextlich.at Wed Mar 13 11:24:48 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Wed, 13 Mar 2013 11:24:48 +0100 Subject: Now I have only one problem In-Reply-To: References: Message-ID: <20130313102448.GA16463@quelltextlich.at> Hi Alina, On Wed, Mar 13, 2013 at 04:53:14AM +0100, Alina Friedrichsen wrote: > root at e525:/home/x-alina# LANG=C gpg2 --card-status > gpg: OpenPGP card not available: Not supported At first sight, it seems to me that the only code path that allows to come up with this error message is starting gpg-agent with the --disable-scdaemon option. I guess you would not want that. So try to make sure to /not/ pass that option. * When starting daemon manually, do not pass that option. * When having gnupg start the daemons for you, check that ~/.gnupg/gpg-agent.conf is free of disable-scdaemon. Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Wed Mar 13 12:22:40 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Wed, 13 Mar 2013 12:22:40 +0100 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <87obeo2vg7.fsf@alice.fifthhorseman.net> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> Message-ID: <20130313112240.GB16463@quelltextlich.at> Hi Daniel, since you said to have patched GnuPG 1.4.12, I tried on GnuPG 2.0.19. See below. On Tue, Mar 12, 2013 at 04:51:20PM -0400, Daniel Kahn Gillmor wrote: > Below is an example OpenPGP key with three subkeys: > > * the first (1024bit DSA) is marked authentication-capable, with a > critical notation that gpg doesn't know about. gpg marks this with > usage flags "a", depsite the critical notation. should this subkey > binding signature be acceptable to gpg even in the face of the > critical notation? With GnuPG 2.0.19, this signature is considered a bad signature. It says so, when trying to import the key: __________________________________________________________ christian at spencer cwd: ~ LC_ALL=C gpg --import ~/example.key gpg: assuming bad signature from key C9A3FA35 due to an unknown critical bit gpg: key C9A3FA35: "test key with dsa subkey" not changed gpg: Total number processed: 1 gpg: unchanged: 1 And in fact GnuPG 2.0.19 does not add the first subkey: __________________________________________________________ christian at spencer cwd: ~ LC_ALL=C gpg --edit-key C9A3FA35 gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 1024R/C9A3FA35 created: 2013-03-05 expires: 2013-04-04 usage: SC trust: unknown validity: unknown sub 512D/48B80074 created: 2013-03-07 expires: 2013-04-06 usage: SCA sub 768D/5BA8B581 created: 2013-03-12 expires: 2013-03-19 usage: SCA [ unknown] (1). test key with dsa subkey > * the second (512bit DSA) has no usage flags subpacket at all in the > binding signature. gpg marks this "sca", presumably because those > are all the capabilities supported by DSA. As seen above, this also holds true for GnuPG 2.0.19 > * the third (768bit DSA) has a usage flags subpacket with all bits set > to zero. gpg marks this also as "sca". As seen above, this also holds true for GnuPG 2.0.19 > So i think we need to think through a few questions: > > * what should GnuPG do when presented with a subkey binding signatures > with critical subpackets that it does not understand? About the critical bit, RFC 4880 ?5.2.3.1 says Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. So I'd say, GnuPG should do just that. GnuPG should consider the signature to be in error. > * what should GnuPG do when presented with a subkey binding signature > with an all-zero usage flags subpacket? RFC 4880, ? 5.2.3.21: If a list is shorter than an implementation expects, the unstated flags are considered to be zero. Although this sentence comes with a vague precondition of the implementation expecting something, I'd nevertheless interpret a key flags subpacket being all-zero, as signalling that this key should /not/ be used for signing, encrypting, ... > * (less importantly) should GnuPG be able to generate such a subkey > binding signature? If it's hidden behind --expert, I would not mind. However, I do not see a really compelling use case for allowing to generate such a key. Well, maybe the OTR usage you mentioned on the IETF mailing list just is such a use case :-) Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Mar 13 16:17:24 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Mar 2013 16:17:24 +0100 Subject: [PATCH] agent and scd: Don't prepend message digest In-Reply-To: <1363136721.2682.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 13 Mar 2013 10:05:21 +0900") References: <1363076366.12571.4.camel@cfw2.gniibe.org> <874ngg65wq.fsf@vigenere.g10code.de> <1363136721.2682.2.camel@cfw2.gniibe.org> Message-ID: <87d2v349dn.fsf@vigenere.g10code.de> On Wed, 13 Mar 2013 02:05, gniibe at fsij.org said: > I assume that the only client of SCDaemon is GPG-Agent of the same > version (or a bit old versions, but not all of past versions). I I might have agreed to it in the past, but we gpg 1.4 which needs to use gpg-agent/scdaemon for smartcard access because scdameon has exclusive access to the smartcard. Thus gpg 1.4 uses "SCD foo" commands to communicate with scdameon. Also for signing and decryption. Scute and Poldi also use SCD commands. A quick check however shows that they don't use "SCD" command for signing. Thus this should not be a problem. > change will cause an error. I think that there will be no problem, > however, because there is always the prefix for RSA (for recent > GPG-Agent). Except for gpg 1.4. We may eventually drop smartcard support from 1.4 but I would hesitate to do this right now. Thus we need to keep the prefixing for use by gpg 1.4 - we might be able to detect a usage pattern if gpg 1.4 is in use and then enbale the prefixing. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Wed Mar 13 18:48:36 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 13 Mar 2013 18:48:36 +0100 Subject: Now I have only one problem In-Reply-To: <1363154405.23342.0.camel@cfw2.gniibe.org> References: <1363148881.4193.9.camel@e525.x-alina.name> <1363154405.23342.0.camel@cfw2.gniibe.org> Message-ID: <1363196916.4724.1.camel@e525.x-alina.name> Thank you very much. My card life again. :) Alina Am Mittwoch, den 13.03.2013, 15:00 +0900 schrieb NIIBE Yutaka: > On 2013-03-13 at 05:28 +0100, Alina Friedrichsen wrote: > > So, card death, reader waggly: > > I will send it back to factory. > > I'm very sorry. I did, and my card was also died (once). > > For my card, I managed to get its life back again with following script. > > $ python come-back-openpgpcard.py > > You need to install python-pyscard (this is package name in Debian), > the PyScard library to use this. > > > --------------------------- come-back-openpgpcard.py > #! /usr/bin/python > > # Assume only single CCID device is attached to computer with card > > from smartcard.CardType import AnyCardType > from smartcard.CardRequest import CardRequest > from smartcard.util import toHexString > > class Card(object): > def __init__(self): > cardtype = AnyCardType() > cardrequest = CardRequest(timeout=10, cardType=cardtype) > cardservice = cardrequest.waitforcard() > self.connection = cardservice.connection > > if __name__ == '__main__': > card = Card() > card.connection.connect() > > ident = card.connection.getReader() > print "Reader:", ident > print "ATR:", toHexString( card.connection.getATR() ) > > apdu = [ 0x00, 0xa4, 0x04, 0x00, 6, 0xd2, 0x76, 0x00, 0x01, 0x24, 0x01 ] > response, sw1, sw2 = card.connection.transmit(apdu) > print "%02x %02x %s" % (sw1, sw2, response) > apdu = [ 0x00, 0x44, 0x00, 0x00 ] > response, sw1, sw2 = card.connection.transmit(apdu) > print "%02x %02x %s" % (sw1, sw2, response) > card.connection.disconnect() From x-alina at gmx.net Wed Mar 13 18:55:06 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 13 Mar 2013 18:55:06 +0100 (CET) Subject: Suggestion Message-ID: Add a factory reset command is better then such hacks. If it deletes first all keys and the other stuff and set then back the PINs, it's no security vulnerability. From dkg at fifthhorseman.net Wed Mar 13 22:30:36 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Mar 2013 17:30:36 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <20130313112240.GB16463@quelltextlich.at> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <20130313112240.GB16463@quelltextlich.at> Message-ID: <5140EFFC.807@fifthhorseman.net> On 03/13/2013 07:22 AM, Christian Aistleitner wrote: > With GnuPG 2.0.19, this signature is considered a bad signature. It > says so, when trying to import the key: Ah, interesting. Thanks for pointing this out. I was only looking at it from the keyring which generated the subkey binding signature in the first place. When i gpg --import with 1.4.12, i see something similar to what you see: 0 dkg at alice:~/src/gnupg/usage-tests$ chmod 0700 x 0 dkg at alice:~/src/gnupg/usage-tests$ export GNUPGHOME=x 0 dkg at alice:~/src/gnupg/usage-tests$ gpg --import < example.key gpg: keyring `x/secring.gpg' created gpg: keyring `x/pubring.gpg' created gpg: assuming bad signature from key C9A3FA35 due to an unknown critical bit gpg: x/trustdb.gpg: trustdb created gpg: key C9A3FA35: public key "test key with dsa subkey" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) 0 dkg at alice:~/src/gnupg/usage-tests$ gpg --edit-key test gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 1024R/C9A3FA35 created: 2013-03-05 expires: 2013-04-04 usage: SC trust: unknown validity: unknown sub 512D/48B80074 created: 2013-03-07 expires: 2013-04-06 usage: SCA sub 768D/5BA8B581 created: 2013-03-12 expires: 2013-03-19 usage: SCA [ unknown] (1). test key with dsa subkey gpg> >> * what should GnuPG do when presented with a subkey binding signature >> with an all-zero usage flags subpacket? > > RFC 4880, ? 5.2.3.21: > > If a > list is shorter than an implementation expects, the unstated flags > are considered to be zero. > > Although this sentence comes with a vague precondition of the > implementation expecting something, I'd nevertheless interpret a key > flags subpacket being all-zero, as signalling that this key should > /not/ be used for signing, encrypting, ... So there might be three cases (setting aside the notation business for the moment): 0) the first case has no key usage flags subpacket at all -- this might be a legacy key, for example, before the usage flag subpacket existed. 1) a key usage flags subpacket exists, but is 0 octets 2) a key usage flags subpacket exists, is 1 octet in length, with a value of 0x00. I think gpg is definitely doing the wrong thing with case 2. I think it's doing the right thing with case 0, and i haven't managed to test case 1 yet (i think case 1 should properly be handled like case 2 based on the section you quote above. >> * (less importantly) should GnuPG be able to generate such a subkey >> binding signature? > > If it's hidden behind --expert, I would not mind. However, I do not > see a really compelling use case for allowing to generate such a > key. Well, maybe the OTR usage you mentioned on the IETF mailing list > just is such a use case :-) that's why i'm asking :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dshaw at JABBERWOCKY.COM Wed Mar 13 23:27:34 2013 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Wed, 13 Mar 2013 18:27:34 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <87obeo2vg7.fsf@alice.fifthhorseman.net> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> Message-ID: On Mar 12, 2013, at 4:51 PM, Daniel Kahn Gillmor wrote: > following a discussion on the IETF mailing list [0], i did a couple of > experiments with GnuPG, to see if i could make a subkey with the usage > flags subpacket set to an all-zero byte, or with a critical notation. > (this would allow specific alternate uses to be identified with notation > subpackets without needing to navigate the WG resistance against > expanding the usage flag bits) > > Below is an example OpenPGP key with three subkeys: > > * the first (1024bit DSA) is marked authentication-capable, with a > critical notation that gpg doesn't know about. gpg marks this with > usage flags "a", depsite the critical notation. should this subkey > binding signature be acceptable to gpg even in the face of the > critical notation? It should not be acceptable. If someone imports this key, the marked subkey is left off. The problem here seems to be that you generated (rather than imported) the key. It's a bit of a messy situation. On the one hand, you have a subkey with a critical notation so it shouldn't be used, but on the other hand, how could you generate such a thing if GPG didn't at least accept it to the point of generating it? Note if you export that key, you won't be able to re-import it. > * the second (512bit DSA) has no usage flags subpacket at all in the > binding signature. gpg marks this "sca", presumably because those > are all the capabilities supported by DSA. Correct. Lacking a key flags subpacket, the assumption is that all uses are permissible. There is a minor caveat here where subkeys do not get the "certify" capability for web of trust reasons. > * the third (768bit DSA) has a usage flags subpacket with all bits set > to zero. gpg marks this also as "sca". Yes. Having no flags set at all is treated as if there is no subpacket present. This may not be the best behavior. > I think GnuPG's handling of (at least) the third subkey is buggy, and > potentially dangerously so -- for example, if the "certify" bit is > present and set to 0, GnuPG should not accept a certification made from > the given subkey. It doesn't. Try it. The certify bit on subkeys is a slightly weird case. Briefly, all primary keys MUST be able to certify, but subkeys are not required to. In practice, GPG simply doesn't allow *any* subkey to certify. Even if you hacked the code to force creation of such a certification, GPG does not include it in the web of trust. David From gniibe at fsij.org Thu Mar 14 01:18:05 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Mar 2013 09:18:05 +0900 Subject: [PATCH] agent and scd: Don't prepend message digest In-Reply-To: <87d2v349dn.fsf@vigenere.g10code.de> References: <1363076366.12571.4.camel@cfw2.gniibe.org> <874ngg65wq.fsf@vigenere.g10code.de> <1363136721.2682.2.camel@cfw2.gniibe.org> <87d2v349dn.fsf@vigenere.g10code.de> Message-ID: <1363220285.2878.1.camel@cfw2.gniibe.org> On 2013-03-13 at 16:17 +0100, Werner Koch wrote: > On Wed, 13 Mar 2013 02:05, gniibe at fsij.org said: > > > I assume that the only client of SCDaemon is GPG-Agent of the same > > version (or a bit old versions, but not all of past versions). I > > I might have agreed to it in the past, but we gpg 1.4 which needs to use > gpg-agent/scdaemon for smartcard access because scdameon has exclusive > access to the smartcard. Thus gpg 1.4 uses "SCD foo" commands to > communicate with scdameon. Also for signing and decryption. > > Scute and Poldi also use SCD commands. A quick check however shows that > they don't use "SCD" command for signing. Thus this should not be a > problem. Thank you for pointing this out. It was my near sight. Now, I understand that there are GPG 1.4 or other clients. I will revise my work to keep its compatibility. Sure, I will test with GPG 1.4 and Scute. I don't have any experience with Poldi, but I will examine its source code too. -- From gniibe at fsij.org Thu Mar 14 08:01:30 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Mar 2013 16:01:30 +0900 Subject: scd: ccid-driver improvement Message-ID: <1363244490.2878.7.camel@cfw2.gniibe.org> Sending same patch here, again. This time, my intention is to include this change to both of STABLE-BRANCH-2-0 and master. In January 2012, I changed the same line of ccid_transceive_apdu_level. The git commit ID is: 5988c8bfb7eafaca53c8abeb793f189acd3177c6 At that time, Gnuk used extended APDU level exchange, and the magic number 289 came from its 2048-bit key import communication. For a reader which supports extended APDU level exchange, 289 is not enough for a key > 2048-bit (key import and decryption). Thus, I'd like to fix the checking again. As we discussed in 2012, this is a kind of ad hoc change; It works for now, but it won't work for 8192-bit key. It would be good to support full of extended APDU exchange level communication. My opinion is that full support of extended APDU exchange level communication is still not worth now. This change is OK for me. Any comments? diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index ccf579c..dd9fabe 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -2840,7 +2840,7 @@ ccid_transceive_apdu_level (ccid_driver_t handle, /* The maximum length for a short APDU T=1 block is 261. For an extended APDU T=1 block the maximum length 65544; however extended APDU exchange level is not fully supported yet. */ - if (apdulen > 289) + if (apdulen > sizeof (send_buffer) - 10) return CCID_DRIVER_ERR_INV_VALUE; /* Invalid length. */ msg[0] = PC_to_RDR_XfrBlock; -- From gniibe at fsij.org Thu Mar 14 08:27:50 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Mar 2013 16:27:50 +0900 Subject: [PATCH v2] Add pinpad support for REINER SCT cyberJack go In-Reply-To: References: Message-ID: <1363246070.2878.9.camel@cfw2.gniibe.org> On 2013-03-11 at 14:26 +0100, Alina Friedrichsen wrote: > This patch adds pinpad support for the REINER SCT cyberJack go CCID reader. > Please put it into stable. [...] > Signed-off-by: Alina Friedrichsen Reviewd-by: NIIBE Yutaka I think that this is a tiny change and it is good to have it for both of STABLE-BRANCH-2-0 and master. I will add 0c4b:0500 REINER SCT cyberJack RFID standard, then. -- From wk at gnupg.org Thu Mar 14 12:47:53 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Mar 2013 12:47:53 +0100 Subject: [PATCH] agent and scd: Don't prepend message digest In-Reply-To: <1363220285.2878.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 14 Mar 2013 09:18:05 +0900") References: <1363076366.12571.4.camel@cfw2.gniibe.org> <874ngg65wq.fsf@vigenere.g10code.de> <1363136721.2682.2.camel@cfw2.gniibe.org> <87d2v349dn.fsf@vigenere.g10code.de> <1363220285.2878.1.camel@cfw2.gniibe.org> Message-ID: <87hake2oeu.fsf@vigenere.g10code.de> On Thu, 14 Mar 2013 01:18, gniibe at fsij.org said: > Thank you for pointing this out. It was my near sight. Now, I > understand that there are GPG 1.4 or other clients. Yeah, existing 1.4 installations are worth to care about. Scute and Poldi are not in that widespread use and could easily be updated. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Mar 14 12:46:38 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Mar 2013 12:46:38 +0100 Subject: scd: ccid-driver improvement In-Reply-To: <1363244490.2878.7.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 14 Mar 2013 16:01:30 +0900") References: <1363244490.2878.7.camel@cfw2.gniibe.org> Message-ID: <87li9q2ogx.fsf@vigenere.g10code.de> On Thu, 14 Mar 2013 08:01, gniibe at fsij.org said: > As we discussed in 2012, this is a kind of ad hoc change; It works for > now, but it won't work for 8192-bit key. It would be good to support We will never see such keys on smart cards. All standards are switching to ECC because such long RSA keys woul require too much cpu power on the the card and increase the amount of I/O. > My opinion is that full support of extended APDU exchange level > communication is still not worth now. This change is OK for me. I concur. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Thu Mar 14 14:47:16 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Thu, 14 Mar 2013 14:47:16 +0100 Subject: [PATCH v2] Add pinpad support for REINER SCT cyberJack go In-Reply-To: <1363246070.2878.9.camel@cfw2.gniibe.org> References: <1363246070.2878.9.camel@cfw2.gniibe.org> Message-ID: <1363268836.4377.24.camel@e525.x-alina.name> Hallo NIIBE Yutaka! > Reviewd-by: NIIBE Yutaka > > I think that this is a tiny change and it is good to have it for both > of STABLE-BRANCH-2-0 and master. Full ACK. > I will add 0c4b:0500 REINER SCT > cyberJack RFID standard, then. This reader is not CCID. You need the libifd-cyberjack6 driver. I will buy a cyberJack RFID komfort and test it over the pcscd way. Bye Alina From nicholas.cole at gmail.com Thu Mar 14 15:34:46 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 14 Mar 2013 14:34:46 +0000 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: References: <87obeo2vg7.fsf@alice.fifthhorseman.net> Message-ID: I'm a little worried by this thread and a similar thread. If I understand correctly, the key usage flags are there in large part to ensure the integrity of the underlying cryptography by ensuring that a key meant for signing is not used for encryption and vice-versa, and thereby to close some potential weaknesses. I can see that the "Certification" flag muddles things a little, but I think the principle is still there that the flags designate fairly fundamental operations. Hints as to what a key should be used for are typically part of the User-id packets. And perhaps there is no harm in having a subkey marked with a critical notation hinting at an application-sepecific use. And if it really is "critical" that this be observed, then of course applications that do not understand that notation should not use the key. All the same, wanting to use one subkey for one application (email) and other for another service seems to me to be attempting to push the key-subkey framework beyond its design limitations. I *certainly* think you shouldn't be generating keys that have no usage flags. That looks to me as if it is certain to (at best) introduce interoperability issues and (at worse) introduce the potential for some security-undermining errors. But I'm not a cryptographer, so perhaps I've misunderstood. At any rate, I've always thought that people would be best off generating a new key for each individual use (the classic case being home vs work) rather than attempting to do complicated operations involving subkeys and the like. But perhaps I've just misunderstood the intention. Best wishes, N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Mar 14 17:02:29 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 Mar 2013 12:02:29 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: References: <87obeo2vg7.fsf@alice.fifthhorseman.net> Message-ID: <5141F495.8010704@fifthhorseman.net> On 03/14/2013 10:34 AM, Nicholas Cole wrote: > Hints as to what a key should be used for are typically part of the User-id > packets. I disagree with this pretty strongly. User IDs are associated with primary keys, and subkeys are also associated with primary keys. There is no linkage between User IDs and subkeys. Also, a User ID is supposed to indentify the keyholder -- placing non-identity-related text in the User ID can be problematic. If a keyholder wants to indicate that a given subkey is for a specific use, this should be done in the subkey binding signature; with key usage flags if they are able to express the desired details, or with notations (or other subpackets?) if key usage flags are insufficient. > All the same, wanting to use one subkey for one application (email) and > other for another service seems to me to be attempting to push the > key-subkey framework beyond its design limitations. This is precisely what the key-subkey framework is designed to do as far as i understand it. why is this pushing it beyond its design limitations? > I *certainly* think > you shouldn't be generating keys that have no usage flags. That looks to > me as if it is certain to (at best) introduce interoperability issues and > (at worse) introduce the potential for some security-undermining errors. Here's the concern: if we use a known usage flag, one that indicates that keys should be acceptable in a given context, then they will most likely be used in that context. So if you want to add a subkey that should *not* be used in any of those contexts, you need to ensure all those usage flag bits are cleared. Alternately, you can pick the broader category via the usage flag (e.g. authentication-capablility), and supply a notation to indicate what scope it is supposed to apply to. If you do that, and you don't mark the notation as "critical" then the key usage will be applied more broadly. I don't really see a clear alternative, though i'm willing to consider other proposals. > At any rate, I've always thought that people would be best off generating a > new key for each individual use (the classic case being home vs work) > rather than attempting to do complicated operations involving subkeys and > the like. I think this would be a waste of the existing certification infrastructure, and it would make it even harder to verify people across domains. How many fingerprints should two people need to exchange in person to be able to identify each other online? Practically, one fingerprint per person is about the upper limit of what most people are willing to do. OpenPGP's subkey mechanism permits people to bootstrap a wide variety of keys useful for different contexts off of a single exchange of a primary key fingerprint. Suggesting that people maintain multiple primary keys as part of managing a single identity seem like it would make it more difficult for people to participate in a process that is already probably more complicated than people want it to be. I think that's a bad tradeoff. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Mar 14 17:05:36 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 Mar 2013 12:05:36 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: References: <87obeo2vg7.fsf@alice.fifthhorseman.net> Message-ID: <5141F550.5020702@fifthhorseman.net> On 03/13/2013 06:27 PM, David Shaw wrote: > Yes. Having no flags set at all is treated as if there is no subpacket present. This may not be the best behavior. yeah, i think this needs fixing. >> I think GnuPG's handling of (at least) the third subkey is buggy, and >> potentially dangerously so -- for example, if the "certify" bit is >> present and set to 0, GnuPG should not accept a certification made from >> the given subkey. > > It doesn't. Try it. The certify bit on subkeys is a slightly weird case. Briefly, all primary keys MUST be able to certify, but subkeys are not required to. In practice, GPG simply doesn't allow *any* subkey to certify. Even if you hacked the code to force creation of such a certification, GPG does not include it in the web of trust. OK, i'm glad to hear that certification isn't treated this way (though it's a bit weird for gpg to show the "C" usage flag if it doesn't consider it acceptable). However (certification aside), the other capabilities are just as relevant. it's not appropriate for a subkey marked clearly as "not for signing" to be treated as acceptable for signing documents, and it would be a mistake for a subkey to be considered acceptable for encryption if the keyholder had explicitly marked it as "not for use with encryption". --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Thu Mar 14 18:47:36 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 14 Mar 2013 17:47:36 +0000 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <5141F495.8010704@fifthhorseman.net> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F495.8010704@fifthhorseman.net> Message-ID: On Thu, Mar 14, 2013 at 4:02 PM, Daniel Kahn Gillmor wrote: > On 03/14/2013 10:34 AM, Nicholas Cole wrote: > > > Hints as to what a key should be used for are typically part of the > User-id > > packets. > > I disagree with this pretty strongly. User IDs are associated with > primary keys, and subkeys are also associated with primary keys. There > is no linkage between User IDs and subkeys. > > Also, a User ID is supposed to indentify the keyholder -- placing > non-identity-related text in the User ID can be problematic. > I think we just disagree, and I completely respect your opinion and what you are trying to achieve. I don't (quite) see the point of having keys dedicated to (e.g.) email vs instant messaging, but I do see what you are trying to achieve. Of course, you are right that UIDs attach to the primary key not the subkey. But the second part of what you've written above is not really true. Most UID packets contain an email address, or things that look very much like email addresses. I know that email addresses are sometimes used as IDs on different services, but it would be very possible (if you were prepared to have different primary keys for different purposes) to specify a service that they key was used for in the UID (either in the "email" or the "comment" part. There is already a huge blurring of the line between identity and application in the UID, both by design and in use. If a keyholder wants to indicate that a given subkey is for a specific > use, this should be done in the subkey binding signature; with key usage > flags if they are able to express the desired details, or with notations > (or other subpackets?) if key usage flags are insufficient. > > > All the same, wanting to use one subkey for one application (email) and > > other for another service seems to me to be attempting to push the > > key-subkey framework beyond its design limitations. > > This is precisely what the key-subkey framework is designed to do as far > as i understand it. why is this pushing it beyond its design limitations? Again, I'm not sure this is true. The subkey was intended to do two things: First and foremost to make sure that the same key was not used for both signing and encryption (generally, not on an application-sepcific basis). Second to make sure that it was possible to change encryption (and perhaps signing) keys while preserving the trust of the primary key (in an attempt to solve the problem of a reluctance to change primary keys every few years). What you are trying to do is introduce the idea of application-sepcific keys. It seems like a niche area to me. Totally fine if you can achieve it with notations, of course, but probably not something with wide application. I put my initial point badly, and perhaps what I mean to propose is this: - don't get rid of the usage flags, because I think there is an importance of saying "it's ok to use this key for encryption" or for signing or whatever. But make sure that your application uses BOTH the notations and the usage flags when deciding whether to use a particular subkey for a given purpose. Set the critical notation bit for those subkeys that you absolutely never want to be used outside of a specific application, and hope that OpenPGP software respects the standard enough to ignore them. > Here's the concern: if we use a known usage flag, one that indicates > that keys should be acceptable in a given context, then they will most > likely be used in that context. So if you want to add a subkey that > should *not* be used in any of those contexts, you need to ensure all > those usage flag bits are cleared. Well, as I say, isn't it the case that the critical notation bit achieves this without removing the flags? > > > At any rate, I've always thought that people would be best off > generating a > > new key for each individual use (the classic case being home vs work) > > rather than attempting to do complicated operations involving subkeys and > > the like. > > I think this would be a waste of the existing certification > infrastructure, and it would make it even harder to verify people across > domains. How many fingerprints should two people need to exchange in > person to be able to identify each other online? Well, this is a bigger problem with openpgp. You are quite right. The web of trust has never worked quite as easily as hoped (is this related to the Eternal September problem?) and the problem looks set to get worse if a new key standard introduces even longer fingerprints that people will be even more reluctant to exchange. I don't have a solution, of course. I completely accept that you don't want to maintain different primary keys for different purposes. Though just for the sake of completeness I'll point out that you could use Trust Signatures and multiple primary keys to achieve the effect of what you want. Maybe. There is a practical security point here, too. In the real world, it would be much easier, (for example) when leaving an employer, to leave a copy of a primary key and subkeys than to leave a collection of subkeys (even though I know it is technically possible.) N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Mar 14 20:52:36 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Mar 2013 20:52:36 +0100 Subject: Suggestion In-Reply-To: (Alina Friedrichsen's message of "Wed, 13 Mar 2013 18:55:06 +0100 (CET)") References: Message-ID: <87y5dp21yz.fsf@vigenere.g10code.de> On Wed, 13 Mar 2013 18:55, x-alina at gmx.net said: > Add a factory reset command is better then such hacks. > If it deletes first all keys and the other stuff and > set then back the PINs, it's no security vulnerability. People tend to try out features and may complain after they destroyed their production key. Thus I consider a feature to make a factory reset a bit more complicated. After all it is just running a certain script. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Mar 15 00:52:55 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 15 Mar 2013 08:52:55 +0900 Subject: scd: ccid-driver improvement In-Reply-To: <87li9q2ogx.fsf@vigenere.g10code.de> References: <1363244490.2878.7.camel@cfw2.gniibe.org> <87li9q2ogx.fsf@vigenere.g10code.de> Message-ID: <1363305175.2837.0.camel@cfw2.gniibe.org> I applied the patch to both branches (STABLE-BRANCH-2-0 and master). Now, users of internal CCID driver can enjoy the following change of GnuPG, finally. commit ab4ea45f54006eba55db11263431c4c0c4f557dc Author: Werner Koch Date: Tue Nov 6 14:39:22 2012 +0100 Allow decryption with card keys > 3072 bit -- From gniibe at fsij.org Fri Mar 15 01:14:20 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 15 Mar 2013 09:14:20 +0900 Subject: [PATCH v2] Add pinpad support for REINER SCT cyberJack go In-Reply-To: <1363268836.4377.24.camel@e525.x-alina.name> References: <1363246070.2878.9.camel@cfw2.gniibe.org> <1363268836.4377.24.camel@e525.x-alina.name> Message-ID: <1363306460.2837.1.camel@cfw2.gniibe.org> On 2013-03-14 at 14:47 +0100, Alina Friedrichsen wrote: > > Reviewd-by: NIIBE Yutaka > > > > I think that this is a tiny change and it is good to have it for both > > of STABLE-BRANCH-2-0 and master. > > Full ACK. Please don't get me wrong. I didn't mean your contribution is "tiny". It is great news for users of the reader, since they won't need to install and run PC/SC and can keep their system simple. What I meant was how large change is legally significant for copyright. > > I will add 0c4b:0500 REINER SCT > > cyberJack RFID standard, then. > > This reader is not CCID. You need the libifd-cyberjack6 driver. > I will buy a cyberJack RFID komfort and test it over the pcscd way. Thanks for the information. So, I should not add it to the internal CCID driver. -- From gniibe at fsij.org Fri Mar 15 09:14:54 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 15 Mar 2013 17:14:54 +0900 Subject: NeuG 0.06 and Gnuk 1.0.4 Message-ID: <1363335294.2837.7.camel@cfw2.gniibe.org> NeuG 0.06 and Gnuk 1.0.4 were released. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. Gnuk is an implementation of Cryptographic Token for GnuPG, and it runs on STM32F103. There are mostly no user visible changes, but maintenance of related tools. Highlights of Gnuk are: * Relocatable reGNUal The upgrade helper, reGNUal, is now relocatable (other than the first vector table). It runs well when loaded at different address. This makes the upgrade procedure more stable. * Compilation by newer GNU Toolchain Now, Gnuk can be compiled with newer GNU Toolchain, specifically gcc-arm-none-eabi-4_7-2012q4 (of GCC 4.7.x and GNU Binutils 2.22). Old versions of Gnuk had problem for ChibiOS_2.0.8/os/ports/GCC/ARMCMx/cmsis/core_cm3.c, which was fixed. * Data object 0x0073 Data object 0x0073 is now available. Here are some links for Gnuk and FST-01 (the hardware). Gnuk Repository: http://gitorious.org/gnuk Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 Q&A site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Since the machine which runs no-passwd.net will be gone this month, you will be not able to access to the site for a while. We have a plan to migrate to another machine. Enjoy, -- From x-alina at gmx.net Fri Mar 15 15:03:11 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Fri, 15 Mar 2013 15:03:11 +0100 Subject: Testing pinpad support for REINER SCT cyberJack RFID komfort Message-ID: <1363356191.4018.8.camel@e525.x-alina.name> It does not work. Without pinpad it works. I have installed libifd-cyberjack6 and pcscd. scdaemon.conf: enable-pinpad-varlen debug-level guru debug-all log-file /var/tmp/scd.log Any ideas? -------------- next part -------------- A non-text attachment was scrubbed... Name: scd.log Type: text/x-log Size: 15754 bytes Desc: not available URL: From abel at guardianproject.info Fri Mar 15 13:45:15 2013 From: abel at guardianproject.info (Abel Luck) Date: Fri, 15 Mar 2013 12:45:15 +0000 Subject: scd: ccid-driver improvement In-Reply-To: <1363305175.2837.0.camel@cfw2.gniibe.org> References: <1363244490.2878.7.camel@cfw2.gniibe.org> <87li9q2ogx.fsf@vigenere.g10code.de> <1363305175.2837.0.camel@cfw2.gniibe.org> Message-ID: <514317DB.2080107@guardianproject.info> NIIBE Yutaka: > I applied the patch to both branches (STABLE-BRANCH-2-0 and master). > > Now, users of internal CCID driver can enjoy the following change of > GnuPG, finally. > > commit ab4ea45f54006eba55db11263431c4c0c4f557dc > Author: Werner Koch > Date: Tue Nov 6 14:39:22 2012 +0100 > > Allow decryption with card keys > 3072 bit > Do current Openpgp 2 smart cards support keys > 3072? I remember reading somewhere the cards supported it (despite being labeled as only supporting up to 3072). Is this the case? ~abel From wk at gnupg.org Fri Mar 15 15:52:16 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Mar 2013 15:52:16 +0100 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <5141F550.5020702@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 14 Mar 2013 12:05:36 -0400") References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F550.5020702@fifthhorseman.net> Message-ID: <874ngc1zrz.fsf@vigenere.g10code.de> On Thu, 14 Mar 2013 17:05, dkg at fifthhorseman.net said: > On 03/13/2013 06:27 PM, David Shaw wrote: >> Yes. Having no flags set at all is treated as if there is no subpacket present. This may not be the best behavior. > > yeah, i think this needs fixing. What about this untested patch against master: commit 8f8f3984e82a025cf1384132a419f67f39c7e07d Author: Werner Koch Date: Fri Mar 15 15:46:03 2013 +0100 gpg: Distinguish between missing and cleared key flags. * include/cipher.h (PUBKEY_USAGE_NONE): New. * g10/getkey.c (parse_key_usage): Set new flag. -- We do not want to use the default capabilities (derived from the algorithm) if any key flags are given in a signature. Thus if key flags are used in any way, the default key capabilities are never used. This allows to create a key with key flags set to all zero so it can't be used. This better reflects common sense. Modified g10/getkey.c diff --git a/g10/getkey.c b/g10/getkey.c index 9294273..8cc5601 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -1276,13 +1276,19 @@ parse_key_usage (PKT_signature * sig) if (flags) key_usage |= PUBKEY_USAGE_UNKNOWN; + + if (!key_usage) + key_usage |= PUBKEY_USAGE_NONE; } + else if (p) /* Key flags of length zero. */ + key_usage |= PUBKEY_USAGE_NONE; /* We set PUBKEY_USAGE_UNKNOWN to indicate that this key has a capability that we do not handle. This serves to distinguish between a zero key usage which we handle as the default capabilities for that algorithm, and a usage that we do not - handle. */ + handle. Likewise we use PUBKEY_USAGE_NONE to indicate that + key_flags have been given but they do not specify any usage. */ return key_usage; } Modified include/cipher.h diff --git a/include/cipher.h b/include/cipher.h index 191e197..557ab70 100644 --- a/include/cipher.h +++ b/include/cipher.h @@ -54,9 +54,14 @@ #define PUBKEY_USAGE_SIG GCRY_PK_USAGE_SIGN /* Good for signatures. */ #define PUBKEY_USAGE_ENC GCRY_PK_USAGE_ENCR /* Good for encryption. */ -#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys. */ +#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys.*/ #define PUBKEY_USAGE_AUTH GCRY_PK_USAGE_AUTH /* Good for authentication. */ #define PUBKEY_USAGE_UNKNOWN GCRY_PK_USAGE_UNKN /* Unknown usage flag. */ +#define PUBKEY_USAGE_NONE 256 /* No usage given. */ +#if (GCRY_PK_USAGE_SIGN | GCRY_PK_USAGE_ENCR | GCRY_PK_USAGE_CERT \ + | GCRY_PK_USAGE_AUTH | GCRY_PK_USAGE_UNKN) >= 256 +# error Please choose another value for PUBKEY_USAGE_NONE +#endif #define DIGEST_ALGO_MD5 /* 1 */ GCRY_MD_MD5 #define DIGEST_ALGO_SHA1 /* 2 */ GCRY_MD_SHA1 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Mar 15 17:15:51 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Mar 2013 17:15:51 +0100 Subject: scd: ccid-driver improvement In-Reply-To: <514317DB.2080107@guardianproject.info> (Abel Luck's message of "Fri, 15 Mar 2013 12:45:15 +0000") References: <1363244490.2878.7.camel@cfw2.gniibe.org> <87li9q2ogx.fsf@vigenere.g10code.de> <1363305175.2837.0.camel@cfw2.gniibe.org> <514317DB.2080107@guardianproject.info> Message-ID: <87zjy4zljc.fsf@vigenere.g10code.de> On Fri, 15 Mar 2013 13:45, abel at guardianproject.info said: > Do current Openpgp 2 smart cards support keys > 3072? > > I remember reading somewhere the cards supported it (despite being > labeled as only supporting up to 3072). Is this the case? Right, the ZeitControl cards support 4096. We did not announced it because back then GPG was only able to handle 3072 bit. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Mar 15 18:13:50 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 15 Mar 2013 13:13:50 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <874ngc1zrz.fsf@vigenere.g10code.de> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F550.5020702@fifthhorseman.net> <874ngc1zrz.fsf@vigenere.g10code.de> Message-ID: <514356CE.2000302@fifthhorseman.net> On 03/15/2013 10:52 AM, Werner Koch wrote: > What about this untested patch against master: I just tested it against 1.4.12, and it works for me: 0 dkg at alice:~/src/gnupg/usage-tests$ gpg --list-keys tru::1:1362476341:1365068202:3:1:5 pub:u:1024:1:F848882DC9A3FA35:1362476202:1365068202::u:::scSCA: uid:u::::1362476202::8A8AA0A65B6EC7E3D344786B37602CE3D91C1642::test key with dsa subkey: sub:u:1024:17:39476078BD60397C:1362476412:1365068412:::::a: sub:u:512:17:24940DE048B80074:1362695370:1365287370:::::sca: sub:u:768:17:867E55E65BA8B581:1363119647:1363724447:::::: 0 dkg at alice:~/src/gnupg/usage-tests$ thanks! one minor note below: > diff --git a/include/cipher.h b/include/cipher.h > index 191e197..557ab70 100644 > --- a/include/cipher.h > +++ b/include/cipher.h > @@ -54,9 +54,14 @@ > > #define PUBKEY_USAGE_SIG GCRY_PK_USAGE_SIGN /* Good for signatures. */ > #define PUBKEY_USAGE_ENC GCRY_PK_USAGE_ENCR /* Good for encryption. */ > -#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys. */ > +#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys.*/ ^^ this whitespace change in the comments doesn't seem to be relevant or necessary to me. Do you think it's worth applying the small changeset i suggested earlier that allows creation of all-zero usage flag subpacket as well, or is that something that we should treat separately? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Mar 15 20:13:15 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Mar 2013 20:13:15 +0100 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <514356CE.2000302@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 15 Mar 2013 13:13:50 -0400") References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F550.5020702@fifthhorseman.net> <874ngc1zrz.fsf@vigenere.g10code.de> <514356CE.2000302@fifthhorseman.net> Message-ID: <87r4jgzdbo.fsf@vigenere.g10code.de> On Fri, 15 Mar 2013 18:13, dkg at fifthhorseman.net said: > I just tested it against 1.4.12, and it works for me: Cool. > sub:u:512:17:24940DE048B80074:1362695370:1365287370:::::sca: > sub:u:768:17:867E55E65BA8B581:1363119647:1363724447:::::: What do you think: Should be use '-' to indicate indicate that all-zero key flags case? Without that we won't be able to see unknown key flags. > ^^ this whitespace change in the comments doesn't seem to be relevant or > necessary to me. Set margins to 80 and check again ;-) The line was a little bit too long, thus I fixed that en passant. > Do you think it's worth applying the small changeset i suggested earlier > that allows creation of all-zero usage flag subpacket as well, or is > that something that we should treat separately? Please wait two week so you don't need to exchenge legal papers with the FSF. And please only for master. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Mar 15 21:34:51 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 15 Mar 2013 16:34:51 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <87r4jgzdbo.fsf@vigenere.g10code.de> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F550.5020702@fifthhorseman.net> <874ngc1zrz.fsf@vigenere.g10code.de> <514356CE.2000302@fifthhorseman.net> <87r4jgzdbo.fsf@vigenere.g10code.de> Message-ID: <514385EB.8060102@fifthhorseman.net> On 03/15/2013 03:13 PM, Werner Koch wrote: >> sub:u:512:17:24940DE048B80074:1362695370:1365287370:::::sca: >> sub:u:768:17:867E55E65BA8B581:1363119647:1363724447:::::: > > What do you think: Should be use '-' to indicate indicate that all-zero > key flags case? Without that we won't be able to see unknown key flags. i think the empty string is a clear and unambiguous description of "no key flags set". I don't see a need to special-case a "-", but i'd be willing to entertain the idea if you have a use for it. I'd just leave it as is, if it were up to me. > Set margins to 80 and check again ;-) The line was a little bit too > long, thus I fixed that en passant. if you say so :) >> Do you think it's worth applying the small changeset i suggested earlier >> that allows creation of all-zero usage flag subpacket as well, or is >> that something that we should treat separately? > > Please wait two week so you don't need to exchenge legal papers with the > FSF. And please only for master. My patch was just removing 3 lines ( ~ 30 bytes ) from do_add_key_flags() in g10/keygen.c -- i don't see any sort of copyright pertaining at all, but i'm fine waiting if you want me to wait. Out of curiosity: why only apply this to master? is the goal to ensure that there is a chance for the handlers to propagate widely before any tool makes it easy to build? I'm assuming you are OK applying the subkey flag usage fix (your patch) to all maintained branches; it's just the patch that allows one to generate these keys that would be master-only, right? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Sat Mar 16 02:33:26 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 16 Mar 2013 10:33:26 +0900 Subject: Testing pinpad support for REINER SCT cyberJack RFID komfort In-Reply-To: <1363356191.4018.8.camel@e525.x-alina.name> References: <1363356191.4018.8.camel@e525.x-alina.name> Message-ID: <1363397606.1806.2.camel@latx1.gniibe.org> On 2013-03-15 at 15:03 +0100, Alina Friedrichsen wrote: > 2013-03-15 14:49:29 scdaemon[6085] DBG: send secure: c=00 i=20 p1=00 > p2=82 len=24 pinmax=25 > 2013-03-15 14:49:29 scdaemon[6085] DBG: response: sw=6B80 datalen=2 Here is the error. I guess that pinmax=25 is the issue (as same as cyberJack go). In the function pcsc_pinpad_verify (gnupg/scd/apdu.c), we have: pininfo->maxlen = 25; The value is copied from ccid-driver.c, and this value seemed to come from SPR532. I think that SPR532 is rather special, and it is better to have default value of 15, and let SPR532 to change the value. I will change the code (apdu.c for PC/SC, and ccid-driver.c) to do that. -- From wk at gnupg.org Mon Mar 18 17:13:55 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Mar 2013 17:13:55 +0100 Subject: [Announce] Libgcrypt 1.5.1 released Message-ID: <87zjy08z3w.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.5.1. This is a maintenance release for the stable branch. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.5.1: * Allow empty passphrase with PBKDF2. * Do not abort on an invalid algorithm number in gcry_cipher_get_algo_keylen and gcry_cipher_get_algo_blklen. * Fixed some Valgrind warnings. * Fixed a problem with select and high fd numbers. * Improved the build system * Various minor bug fixes. * Interface changes relative to the 1.5.0 release: GCRYCTL_SET_ENFORCED_FIPS_FLAG NEW. GCRYPT_VERSION_NUMBER NEW. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signature is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.1.tar.bz2 (1468k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.1.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.1.tar.gz (1741k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.1.tar.gz.sig Alternativley you may upgrade version 1.5.0 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0-1.5.1.diff.bz2 (255k) The SHA-1 checksums are: 8b60a26b7eae1a727d58932d6b1efeb5716648ed libgcrypt-1.5.1.tar.bz2 f1ab9ce6ac8c7370d455c77c96b36bf18e2d9c95 libgcrypt-1.5.1.tar.gz e1b2f59a8771e8a0358dbd9a8eaa3250015cf49e libgcrypt-1.5.0-1.5.1.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] See http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 gniibe at fsij.org Tue Mar 19 03:44:06 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 Mar 2013 11:44:06 +0900 Subject: scd: change default value of pinpad maxlen Message-ID: <1363661046.2669.3.camel@cfw2.gniibe.org> Hello, This is a change for STABLE-BRANCH-2-0 and master. The change in ccid-driver.c is to change default pinmax to 15, and let known-reader set specific value. The change in apdu.c is to change default pinmax to 15 (from 25), which is more likely. This is incompatible change, but there is no released version which support pinpad input with PC/SC yet. The code for PC/SC is better to use the new API of PC/SC: FEATURE_GET_TLV_PROPERTIES and bMaxPINSize. I'll try that in near future. I'll apply this, if no objections. diff --git a/scd/apdu.c b/scd/apdu.c index 196d58b..268c2fa 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -2086,7 +2086,7 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, if (!pininfo->minlen) pininfo->minlen = 1; if (!pininfo->maxlen) - pininfo->maxlen = 25; + pininfo->maxlen = 15; /* Note that the 25 is the maximum value the SPR532 allows. */ if (pininfo->minlen < 1 || pininfo->minlen > 25 @@ -2167,7 +2167,7 @@ pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, if (!pininfo->minlen) pininfo->minlen = 1; if (!pininfo->maxlen) - pininfo->maxlen = 25; + pininfo->maxlen = 15; /* Note that the 25 is the maximum value the SPR532 allows. */ if (pininfo->minlen < 1 || pininfo->minlen > 25 diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index dd9fabe..c3a66fa 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -3358,7 +3358,7 @@ ccid_transceive_secure (ccid_driver_t handle, if (!pininfo->minlen) pininfo->minlen = 1; if (!pininfo->maxlen) - pininfo->maxlen = 25; + pininfo->maxlen = 15; /* Note that the 25 is the maximum value the SPR532 allows. */ if (pininfo->minlen < 1 || pininfo->minlen > 25 @@ -3373,13 +3373,14 @@ ccid_transceive_secure (ccid_driver_t handle, case VENDOR_SCM: /* Tested with SPR 532. */ case VENDOR_KAAN: /* Tested with KAAN Advanced (1.02). */ case VENDOR_FSIJ: /* Tested with Gnuk (0.21). */ + pininfo->maxlen = 25; enable_varlen = 1; break; case VENDOR_VASCO: /* Tested with DIGIPASS 920 */ enable_varlen = 1; - pininfo->maxlen = 15; break; case VENDOR_CHERRY: + pininfo->maxlen = 25; enable_varlen = 1; /* The CHERRY XX44 keyboard echos an asterisk for each entered character on the keyboard channel. We use a special variant -- From wk at gnupg.org Tue Mar 19 15:52:13 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Mar 2013 15:52:13 +0100 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <514385EB.8060102@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 15 Mar 2013 16:34:51 -0400") References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F550.5020702@fifthhorseman.net> <874ngc1zrz.fsf@vigenere.g10code.de> <514356CE.2000302@fifthhorseman.net> <87r4jgzdbo.fsf@vigenere.g10code.de> <514385EB.8060102@fifthhorseman.net> Message-ID: <877gl38msi.fsf@vigenere.g10code.de> On Fri, 15 Mar 2013 21:34, dkg at fifthhorseman.net said: > i think the empty string is a clear and unambiguous description of "no > key flags set". I don't see a need to special-case a "-", but i'd be There is another option: Add an '?' if tehre is any unknown key flag. > My patch was just removing 3 lines ( ~ 30 bytes ) from > do_add_key_flags() in g10/keygen.c -- i don't see any sort of copyright > pertaining at all, but i'm fine waiting if you want me to wait. Okay, send again. > Out of curiosity: why only apply this to master? is the goal to ensure > that there is a chance for the handlers to propagate widely before any > tool makes it easy to build? New features should only go into master. In particular changes which are not really needed by todays users. Granted, it is also an incentive to migrate to newer versions. > I'm assuming you are OK applying the subkey flag usage fix (your patch) > to all maintained branches; it's just the patch that allows one to Sure. It is a bug. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Mar 19 16:25:25 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Mar 2013 11:25:25 -0400 Subject: subkey binding signature with no usage flags and/or a critical notation In-Reply-To: <877gl38msi.fsf@vigenere.g10code.de> References: <87obeo2vg7.fsf@alice.fifthhorseman.net> <5141F550.5020702@fifthhorseman.net> <874ngc1zrz.fsf@vigenere.g10code.de> <514356CE.2000302@fifthhorseman.net> <87r4jgzdbo.fsf@vigenere.g10code.de> <514385EB.8060102@fifthhorseman.net> <877gl38msi.fsf@vigenere.g10code.de> Message-ID: <51488365.7000307@fifthhorseman.net> On 03/19/2013 10:52 AM, Werner Koch wrote: > On Fri, 15 Mar 2013 21:34, dkg at fifthhorseman.net said: > >> i think the empty string is a clear and unambiguous description of "no >> key flags set". I don't see a need to special-case a "-", but i'd be > > There is another option: Add an '?' if tehre is any unknown key flag. yep, this makes sense to me, assuming you mean that some unknown key flag is set (that is, that the bit is 1, not 0) -- but ? shouldn't be present if there is an all-zero usage flags subpacket. >> My patch was just removing 3 lines ( ~ 30 bytes ) from >> do_add_key_flags() in g10/keygen.c -- i don't see any sort of copyright >> pertaining at all, but i'm fine waiting if you want me to wait. > > Okay, send again. it's attached to this mail. >> I'm assuming you are OK applying the subkey flag usage fix (your patch) >> to all maintained branches; it's just the patch that allows one to > > Sure. It is a bug. great. thanks! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: allow-empty-usage-flags.patch Type: text/x-patch Size: 219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From x-alina at gmx.net Wed Mar 20 20:35:48 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 20 Mar 2013 20:35:48 +0100 (CET) Subject: Aw: scd: change default value of pinpad maxlen In-Reply-To: <1363661046.2669.3.camel@cfw2.gniibe.org> References: <1363661046.2669.3.camel@cfw2.gniibe.org> Message-ID: Thanks, your patch works fine! :) Is it possible to create a white list with all working readers over pcscd? So that they don't need to set "enable-pinpad-varlen"? gpg1 shows me: gpg: detected reader `REINER SCT cyberJack RFID komfort (2111521960) 00 00' gpg1 access the reader without root. If I run "LANG=C gpg2 --card-status" with my user account it shows me: gpg: selecting openpgp failed: Unsupported certificate gpg: OpenPGP card not available: Unsupported certificate With root it works fine. Thanks again! Alina > Gesendet: Dienstag, 19. M?rz 2013 um 03:44 Uhr > Von: "NIIBE Yutaka" > An: gnupg-devel at gnupg.org > Betreff: scd: change default value of pinpad maxlen > > Hello, > > This is a change for STABLE-BRANCH-2-0 and master. > > The change in ccid-driver.c is to change default pinmax to 15, and let > known-reader set specific value. > > The change in apdu.c is to change default pinmax to 15 (from 25), > which is more likely. This is incompatible change, but there is no > released version which support pinpad input with PC/SC yet. > > The code for PC/SC is better to use the new API of PC/SC: > FEATURE_GET_TLV_PROPERTIES and bMaxPINSize. I'll try that in near > future. > > I'll apply this, if no objections. > > diff --git a/scd/apdu.c b/scd/apdu.c > index 196d58b..268c2fa 100644 > --- a/scd/apdu.c > +++ b/scd/apdu.c > @@ -2086,7 +2086,7 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, > if (!pininfo->minlen) > pininfo->minlen = 1; > if (!pininfo->maxlen) > - pininfo->maxlen = 25; > + pininfo->maxlen = 15; > > /* Note that the 25 is the maximum value the SPR532 allows. */ > if (pininfo->minlen < 1 || pininfo->minlen > 25 > @@ -2167,7 +2167,7 @@ pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, > if (!pininfo->minlen) > pininfo->minlen = 1; > if (!pininfo->maxlen) > - pininfo->maxlen = 25; > + pininfo->maxlen = 15; > > /* Note that the 25 is the maximum value the SPR532 allows. */ > if (pininfo->minlen < 1 || pininfo->minlen > 25 > diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c > index dd9fabe..c3a66fa 100644 > --- a/scd/ccid-driver.c > +++ b/scd/ccid-driver.c > @@ -3358,7 +3358,7 @@ ccid_transceive_secure (ccid_driver_t handle, > if (!pininfo->minlen) > pininfo->minlen = 1; > if (!pininfo->maxlen) > - pininfo->maxlen = 25; > + pininfo->maxlen = 15; > > /* Note that the 25 is the maximum value the SPR532 allows. */ > if (pininfo->minlen < 1 || pininfo->minlen > 25 > @@ -3373,13 +3373,14 @@ ccid_transceive_secure (ccid_driver_t handle, > case VENDOR_SCM: /* Tested with SPR 532. */ > case VENDOR_KAAN: /* Tested with KAAN Advanced (1.02). */ > case VENDOR_FSIJ: /* Tested with Gnuk (0.21). */ > + pininfo->maxlen = 25; > enable_varlen = 1; > break; > case VENDOR_VASCO: /* Tested with DIGIPASS 920 */ > enable_varlen = 1; > - pininfo->maxlen = 15; > break; > case VENDOR_CHERRY: > + pininfo->maxlen = 25; > enable_varlen = 1; > /* The CHERRY XX44 keyboard echos an asterisk for each entered > character on the keyboard channel. We use a special variant > -- > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From x-alina at gmx.net Wed Mar 20 21:33:00 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Wed, 20 Mar 2013 21:33:00 +0100 (CET) Subject: scd: change default value of pinpad maxlen In-Reply-To: References: <1363661046.2669.3.camel@cfw2.gniibe.org>, Message-ID: > Thanks, your patch works fine! :) > Is it possible to create a white list with all working readers > over pcscd? So that they don't need to set "enable-pinpad-varlen"? > > gpg1 shows me: > gpg: detected reader `REINER SCT cyberJack RFID komfort (2111521960) 00 00' It works too with "REINER SCT cyberJack RFID standard (4964284304) 00 00". 0c4b:0500 Alina From gniibe at fsij.org Thu Mar 21 03:49:48 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Mar 2013 11:49:48 +0900 Subject: scd: PC/SC cleanup Message-ID: <1363834188.2686.16.camel@cfw2.gniibe.org> I noticed that there is a discrepancy between PC/SC usage (long vs unsigned long, and DWORD problem: unsigned int vs unsigned long). The cause would be PC/SC lite implementation, but its DWORD problem for MacOS was fixed two years ago: http://anonscm.debian.org/viewvc/pcsclite?view=revision&revision=5505 I think that it is better for GnuPG to follow this change (and to ignore old implementations of PC/SC lite implementations on Mac OS X 64-bit). Following is a change against master, and same patch can be applied to STABLE-BRANCH-2-0 (built, but not tested at all). I also found a bug report in the BTS: http://bugs.g10code.com/gnupg/issue1358 It's a report for 1.4.11, but talking about same issue. diff --git a/scd/apdu.c b/scd/apdu.c index e920678..0eb148e 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -82,6 +82,12 @@ #define DLSTDCALL #endif +#if defined(__APPLE__) || defined(_WIN32) || defined(__CYGWIN__) +typedef unsinged int pcsc_dword_t; +#else +typedef unsigned long pcsc_dword_t; +#endif + /* A structure to collect information pertaining to one reader slot. */ struct reader_table_s { @@ -107,11 +113,11 @@ struct reader_table_s { ccid_driver_t handle; } ccid; struct { - unsigned long context; - unsigned long card; - unsigned long protocol; - unsigned long verify_ioctl; - unsigned long modify_ioctl; + long context; + long card; + pcsc_dword_t protocol; + pcsc_dword_t verify_ioctl; + pcsc_dword_t modify_ioctl; #ifdef NEED_PCSC_WRAPPER int req_fd; int rsp_fd; @@ -250,67 +256,75 @@ struct pcsc_io_request_s typedef struct pcsc_io_request_s *pcsc_io_request_t; +#ifdef __APPLE__ +#pragma pack(1) +#endif + struct pcsc_readerstate_s { const char *reader; void *user_data; - unsigned long current_state; - unsigned long event_state; - unsigned long atrlen; + pcsc_dword_t current_state; + pcsc_dword_t event_state; + pcsc_dword_t atrlen; unsigned char atr[33]; }; +#ifdef __APPLE__ +#pragma pack() +#endif + typedef struct pcsc_readerstate_s *pcsc_readerstate_t; -long (* DLSTDCALL pcsc_establish_context) (unsigned long scope, +long (* DLSTDCALL pcsc_establish_context) (pcsc_dword_t scope, const void *reserved1, const void *reserved2, - unsigned long *r_context); -long (* DLSTDCALL pcsc_release_context) (unsigned long context); -long (* DLSTDCALL pcsc_list_readers) (unsigned long context, + long *r_context); +long (* DLSTDCALL pcsc_release_context) (long context); +long (* DLSTDCALL pcsc_list_readers) (long context, const char *groups, - char *readers, unsigned long*readerslen); -long (* DLSTDCALL pcsc_get_status_change) (unsigned long context, - unsigned long timeout, + char *readers, pcsc_dword_t*readerslen); +long (* DLSTDCALL pcsc_get_status_change) (long context, + pcsc_dword_t timeout, pcsc_readerstate_t readerstates, - unsigned long nreaderstates); -long (* DLSTDCALL pcsc_connect) (unsigned long context, + pcsc_dword_t nreaderstates); +long (* DLSTDCALL pcsc_connect) (long context, const char *reader, - unsigned long share_mode, - unsigned long preferred_protocols, - unsigned long *r_card, - unsigned long *r_active_protocol); -long (* DLSTDCALL pcsc_reconnect) (unsigned long card, - unsigned long share_mode, - unsigned long preferred_protocols, - unsigned long initialization, - unsigned long *r_active_protocol); -long (* DLSTDCALL pcsc_disconnect) (unsigned long card, - unsigned long disposition); -long (* DLSTDCALL pcsc_status) (unsigned long card, - char *reader, unsigned long *readerlen, - unsigned long *r_state, - unsigned long *r_protocol, - unsigned char *atr, unsigned long *atrlen); -long (* DLSTDCALL pcsc_begin_transaction) (unsigned long card); -long (* DLSTDCALL pcsc_end_transaction) (unsigned long card, - unsigned long disposition); -long (* DLSTDCALL pcsc_transmit) (unsigned long card, + pcsc_dword_t share_mode, + pcsc_dword_t preferred_protocols, + long *r_card, + pcsc_dword_t *r_active_protocol); +long (* DLSTDCALL pcsc_reconnect) (long card, + pcsc_dword_t share_mode, + pcsc_dword_t preferred_protocols, + pcsc_dword_t initialization, + pcsc_dword_t *r_active_protocol); +long (* DLSTDCALL pcsc_disconnect) (long card, + pcsc_dword_t disposition); +long (* DLSTDCALL pcsc_status) (long card, + char *reader, pcsc_dword_t *readerlen, + pcsc_dword_t *r_state, + pcsc_dword_t *r_protocol, + unsigned char *atr, pcsc_dword_t *atrlen); +long (* DLSTDCALL pcsc_begin_transaction) (long card); +long (* DLSTDCALL pcsc_end_transaction) (long card, + pcsc_dword_t disposition); +long (* DLSTDCALL pcsc_transmit) (long card, const pcsc_io_request_t send_pci, const unsigned char *send_buffer, - unsigned long send_len, + pcsc_dword_t send_len, pcsc_io_request_t recv_pci, unsigned char *recv_buffer, - unsigned long *recv_len); -long (* DLSTDCALL pcsc_set_timeout) (unsigned long context, - unsigned long timeout); -long (* DLSTDCALL pcsc_control) (unsigned long card, - unsigned long control_code, + pcsc_dword_t *recv_len); +long (* DLSTDCALL pcsc_set_timeout) (long context, + pcsc_dword_t timeout); +long (* DLSTDCALL pcsc_control) (long card, + pcsc_dword_t control_code, const void *send_buffer, - unsigned long send_len, + pcsc_dword_t send_len, void *recv_buffer, - unsigned long recv_len, - unsigned long *bytes_returned); + pcsc_dword_t recv_len, + pcsc_dword_t *bytes_returned); /* Prototypes. */ @@ -1031,7 +1045,7 @@ pcsc_send_apdu_direct (int slot, unsigned char *apdu, size_t apdulen, { long err; struct pcsc_io_request_s send_pci; - unsigned long recv_len; + pcsc_dword_t recv_len; if (!reader_table[slot].atrlen && (err = reset_pcsc_reader (slot))) @@ -1195,7 +1209,7 @@ pcsc_send_apdu (int slot, unsigned char *apdu, size_t apdulen, #ifndef NEED_PCSC_WRAPPER static int -control_pcsc_direct (int slot, unsigned long ioctl_code, +control_pcsc_direct (int slot, pcsc_dword_t ioctl_code, const unsigned char *cntlbuf, size_t len, unsigned char *buffer, size_t *buflen) { @@ -1217,7 +1231,7 @@ control_pcsc_direct (int slot, unsigned long ioctl_code, #ifdef NEED_PCSC_WRAPPER static int -control_pcsc_wrapped (int slot, unsigned long ioctl_code, +control_pcsc_wrapped (int slot, pcsc_dword_t ioctl_code, const unsigned char *cntlbuf, size_t len, unsigned char *buffer, size_t *buflen) { @@ -1326,7 +1340,7 @@ control_pcsc_wrapped (int slot, unsigned long ioctl_code, actual output size will be stored at BUFLEN. Returns: A status word. This routine is used for PIN pad input support. */ static int -control_pcsc (int slot, unsigned long ioctl_code, +control_pcsc (int slot, pcsc_dword_t ioctl_code, const unsigned char *cntlbuf, size_t len, unsigned char *buffer, size_t *buflen) { @@ -1464,8 +1478,8 @@ connect_pcsc_card (int slot) else { char reader[250]; - unsigned long readerlen, atrlen; - unsigned long card_state, card_protocol; + pcsc_dword_t readerlen, atrlen; + long card_state, card_protocol; atrlen = DIM (reader_table[0].atr); readerlen = sizeof reader -1 ; @@ -1662,7 +1676,7 @@ open_pcsc_reader_direct (const char *portstr) long err; int slot; char *list = NULL; - unsigned long nreader, listlen; + pcsc_dword_t nreader, listlen; char *p; slot = new_reader_slot (); @@ -1991,14 +2005,14 @@ check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo) check_again: if (command == ISO7816_VERIFY) { - if (reader_table[slot].pcsc.verify_ioctl == (unsigned long)-1) + if (reader_table[slot].pcsc.verify_ioctl == (pcsc_dword_t)-1) return SW_NOT_SUPPORTED; else if (reader_table[slot].pcsc.verify_ioctl != 0) return 0; /* Success */ } else if (command == ISO7816_CHANGE_REFERENCE_DATA) { - if (reader_table[slot].pcsc.modify_ioctl == (unsigned long)-1) + if (reader_table[slot].pcsc.modify_ioctl == (pcsc_dword_t)-1) return SW_NOT_SUPPORTED; else if (reader_table[slot].pcsc.modify_ioctl != 0) return 0; /* Success */ @@ -2006,8 +2020,8 @@ check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo) else return SW_NOT_SUPPORTED; - reader_table[slot].pcsc.verify_ioctl = (unsigned long)-1; - reader_table[slot].pcsc.modify_ioctl = (unsigned long)-1; + reader_table[slot].pcsc.verify_ioctl = (pcsc_dword_t)-1; + reader_table[slot].pcsc.modify_ioctl = (pcsc_dword_t)-1; sw = control_pcsc (slot, CM_IOCTL_GET_FEATURE_REQUEST, NULL, 0, buf, &len); if (sw) diff --git a/scd/pcsc-wrapper.c b/scd/pcsc-wrapper.c index d0c30d1..a135d1e 100644 --- a/scd/pcsc-wrapper.c +++ b/scd/pcsc-wrapper.c @@ -65,6 +65,12 @@ static int verbose; +#if defined(__APPLE__) || defined(_WIN32) || defined(__CYGWIN__) +typedef unsinged int pcsc_dword_t; +#else +typedef unsigned long pcsc_dword_t; +#endif + /* PC/SC constants and function pointer. */ #define PCSC_SCOPE_USER 0 @@ -112,16 +118,24 @@ struct pcsc_io_request_s { typedef struct pcsc_io_request_s *pcsc_io_request_t; +#ifdef __APPLE__ +#pragma pack(1) +#endif + struct pcsc_readerstate_s { const char *reader; void *user_data; - unsigned long current_state; - unsigned long event_state; - unsigned long atrlen; + pcsc_dword_t current_state; + pcsc_dword_t event_state; + pcsc_dword_t atrlen; unsigned char atr[33]; }; +#ifdef __APPLE__ +#pragma pack() +#endif + typedef struct pcsc_readerstate_s *pcsc_readerstate_t; @@ -129,62 +143,62 @@ static int driver_is_open; /* True if the PC/SC driver has been initialzied and is ready for operations. The following variables are then valid. */ -static unsigned long pcsc_context; /* The current PC/CS context. */ +static long pcsc_context; /* The current PC/CS context. */ static char *current_rdrname; -static unsigned long pcsc_card; -static unsigned long pcsc_protocol; +static long pcsc_card; +static pcsc_dword_t pcsc_protocol; static unsigned char current_atr[33]; static size_t current_atrlen; -long (* pcsc_establish_context) (unsigned long scope, +long (* pcsc_establish_context) (pcsc_dword_t scope, const void *reserved1, const void *reserved2, - unsigned long *r_context); -long (* pcsc_release_context) (unsigned long context); -long (* pcsc_list_readers) (unsigned long context, + long *r_context); +long (* pcsc_release_context) (long context); +long (* pcsc_list_readers) (long context, const char *groups, - char *readers, unsigned long*readerslen); -long (* pcsc_get_status_change) (unsigned long context, - unsigned long timeout, + char *readers, pcsc_dword_t *readerslen); +long (* pcsc_get_status_change) (long context, + pcsc_dword_t timeout, pcsc_readerstate_t readerstates, - unsigned long nreaderstates); -long (* pcsc_connect) (unsigned long context, + pcsc_dword_t nreaderstates); +long (* pcsc_connect) (long context, const char *reader, - unsigned long share_mode, - unsigned long preferred_protocols, - unsigned long *r_card, - unsigned long *r_active_protocol); -long (* pcsc_reconnect) (unsigned long card, - unsigned long share_mode, - unsigned long preferred_protocols, - unsigned long initialization, - unsigned long *r_active_protocol); -long (* pcsc_disconnect) (unsigned long card, - unsigned long disposition); -long (* pcsc_status) (unsigned long card, - char *reader, unsigned long *readerlen, - unsigned long *r_state, - unsigned long *r_protocol, - unsigned char *atr, unsigned long *atrlen); -long (* pcsc_begin_transaction) (unsigned long card); -long (* pcsc_end_transaction) (unsigned long card, - unsigned long disposition); -long (* pcsc_transmit) (unsigned long card, + pcsc_dword_t share_mode, + pcsc_dword_t preferred_protocols, + long *r_card, + pcsc_dword_t *r_active_protocol); +long (* pcsc_reconnect) (long card, + pcsc_dword_t share_mode, + pcsc_dword_t preferred_protocols, + pcsc_dword_t initialization, + pcsc_dword_t *r_active_protocol); +long (* pcsc_disconnect) (long card, + pcsc_dword_t disposition); +long (* pcsc_status) (long card, + char *reader, pcsc_dword_t *readerlen, + pcsc_dword_t *r_state, + pcsc_dword_t *r_protocol, + unsigned char *atr, pcsc_dword_t *atrlen); +long (* pcsc_begin_transaction) (long card); +long (* pcsc_end_transaction) (long card, + pcsc_dword_t disposition); +long (* pcsc_transmit) (long card, const pcsc_io_request_t send_pci, const unsigned char *send_buffer, - unsigned long send_len, + pcsc_dword_t send_len, pcsc_io_request_t recv_pci, unsigned char *recv_buffer, - unsigned long *recv_len); -long (* pcsc_set_timeout) (unsigned long context, - unsigned long timeout); -long (* pcsc_control) (unsigned long card, - unsigned long control_code, + pcsc_dword_t *recv_len); +long (* pcsc_set_timeout) (long context, + pcsc_dword_t timeout); +long (* pcsc_control) (long card, + pcsc_dword_t control_code, const void *send_buffer, - unsigned long send_len, + pcsc_dword_t send_len, void *recv_buffer, - unsigned long recv_len, - unsigned long *bytes_returned); + pcsc_dword_t recv_len, + pcsc_dword_t *bytes_returned); @@ -394,9 +408,9 @@ handle_open (unsigned char *argbuf, size_t arglen) long err; const char * portstr; char *list = NULL; - unsigned long nreader, atrlen; + pcsc_dword_t nreader, atrlen; char *p; - unsigned long card_state, card_protocol; + pcsc_dword_t card_state, card_protocol; unsigned char atr[33]; /* Make sure there is only the port string */ @@ -492,7 +506,7 @@ handle_open (unsigned char *argbuf, size_t arglen) if (!err) { char reader[250]; - unsigned long readerlen; + pcsc_dword_t readerlen; atrlen = 33; readerlen = sizeof reader -1; @@ -626,8 +640,8 @@ handle_reset (unsigned char *argbuf, size_t arglen) { long err; char reader[250]; - unsigned long nreader, atrlen; - unsigned long card_state, card_protocol; + pcsc_dword_t nreader, atrlen; + pcsc_dword_t card_state, card_protocol; (void)argbuf; (void)arglen; @@ -697,7 +711,7 @@ handle_transmit (unsigned char *argbuf, size_t arglen) { long err; struct pcsc_io_request_s send_pci; - unsigned long recv_len; + pcsc_dword_t recv_len; unsigned char buffer[1024]; /* The apdu should at least be one byte. */ @@ -737,8 +751,8 @@ static void handle_control (unsigned char *argbuf, size_t arglen) { long err; - unsigned long ioctl_code; - unsigned long recv_len = 1024; + pcsc_dword_t ioctl_code; + pcsc_dword_t recv_len = 1024; unsigned char buffer[1024]; if (arglen < 4) -- From x-alina at gmx.net Thu Mar 21 04:10:55 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Thu, 21 Mar 2013 04:10:55 +0100 (CET) Subject: Aw: Re: [PATCH v2] Add pinpad support for REINER SCT cyberJack go In-Reply-To: <1363306460.2837.1.camel@cfw2.gniibe.org> References: <1363246070.2878.9.camel@cfw2.gniibe.org> <1363268836.4377.24.camel@e525.x-alina.name>, <1363306460.2837.1.camel@cfw2.gniibe.org> Message-ID: > Please don't get me wrong. I didn't mean your contribution is "tiny". > It is great news for users of the reader, since they won't need to > install and run PC/SC and can keep their system simple. > > What I meant was how large change is legally significant for > copyright. I transfer all on this patch copyright to the Free Software Foundation. Please put it into git master and stable. Alina From x-alina at gmx.net Thu Mar 21 04:11:57 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Thu, 21 Mar 2013 04:11:57 +0100 (CET) Subject: Aw: Re: [PATCH v2] Add pinpad support for REINER SCT cyberJack go Message-ID: > Please don't get me wrong. I didn't mean your contribution is "tiny". > It is great news for users of the reader, since they won't need to > install and run PC/SC and can keep their system simple. > > What I meant was how large change is legally significant for > copyright. I transfer all copyright on this patch to the Free Software Foundation. Please put it into git master and stable. Alina From wk at gnupg.org Thu Mar 21 10:47:04 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Mar 2013 10:47:04 +0100 Subject: scd: PC/SC cleanup In-Reply-To: <1363834188.2686.16.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 21 Mar 2013 11:49:48 +0900") References: <1363834188.2686.16.camel@cfw2.gniibe.org> Message-ID: <87sj3pw0dj.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 03:49, gniibe at fsij.org said: > Following is a change against master, and same patch can be applied to > STABLE-BRANCH-2-0 (built, but not tested at all). Okay. > http://bugs.g10code.com/gnupg/issue1358 > > It's a report for 1.4.11, but talking about same issue. Can you please add a remark that this bug has been solved for 2.x. I don't think we should put any work in fixing it for 1.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Mar 21 10:58:32 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Mar 2013 10:58:32 +0100 Subject: Aw: Re: [PATCH v2] Add pinpad support for REINER SCT cyberJack go In-Reply-To: (Alina Friedrichsen's message of "Thu, 21 Mar 2013 04:11:57 +0100 (CET)") References: Message-ID: <87ehf9vzue.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 04:11, x-alina at gmx.net said: > I transfer all copyright on this patch to the Free Software Foundation. > Please put it into git master and stable. Assigning the copyright is more complicated than this statement. That is one of the reasons why we drop the copyright assignment by Good Friday. By then you only need to post a simple Developer's Certificate of Origin to this mailing list and we are done. Please have some more patience. Salam-Shalom, Werner p.s. Agreed, we could use a DCO right now, but because the termination of my own copyright assignment may be subject to a 30 day notice, I set this flag day, which is easy to remember for me. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Thu Mar 21 16:26:53 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Thu, 21 Mar 2013 16:26:53 +0100 Subject: Hacking GPG-Agent Message-ID: <1363879613.4111.4.camel@e525.x-alina.name> Knowing better hacks? *** /usr/local/bin/gpg *** #!/bin/sh if [ -f "$HOME/.gpg-agent-info" ]; then . "$HOME/.gpg-agent-info" fi gpg2 "$@" *** /home/x-alina/.profile *** # [...] if ! pidof gpg-agent; then gpg-agent --daemon --enable-ssh-support > "$HOME/.gpg-agent-info" fi if [ -f "$HOME/.gpg-agent-info" ]; then . "$HOME/.gpg-agent-info" fi From gniibe at fsij.org Fri Mar 22 03:19:34 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Mar 2013 11:19:34 +0900 Subject: scd: PC/SC cleanup In-Reply-To: <87sj3pw0dj.fsf@vigenere.g10code.de> References: <1363834188.2686.16.camel@cfw2.gniibe.org> <87sj3pw0dj.fsf@vigenere.g10code.de> Message-ID: <1363918774.3334.2.camel@cfw2.gniibe.org> I applied the patch to both (master and STABLE-BRANCH-2-0). On 2013-03-21 at 10:47 +0100, Werner Koch wrote: > > http://bugs.g10code.com/gnupg/issue1358 > > > > It's a report for 1.4.11, but talking about same issue. > > Can you please add a remark that this bug has been solved for 2.x. I > don't think we should put any work in fixing it for 1.4. I tried. But sorry, the issue was not reported by me, thus, I don't have privilege to add an comment to the issue on the BTS. -- From wk at gnupg.org Fri Mar 22 15:18:32 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Mar 2013 15:18:32 +0100 Subject: Hacking GPG-Agent In-Reply-To: <1363879613.4111.4.camel@e525.x-alina.name> (Alina Friedrichsen's message of "Thu, 21 Mar 2013 16:26:53 +0100") References: <1363879613.4111.4.camel@e525.x-alina.name> Message-ID: <87k3ozsekn.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 16:26, x-alina at gmx.net said: > Knowing better hacks? Unless you use a remote file system for ~/.gnupg which does not support Unix domain socket, I suggest to use this: $ echo "enable-ssh-support" >>~/.gnupg/gpg-agent.conf $ echo "use-standard-socket" >>~/.gnupg/gpg-agent.conf $ cat <>~/.bashrc unset GPG_AGENT_INFO unset SSH_AGENT_PID if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh" fi EOF and remove all explicit calls to gpg-agent. The bash code is only required for interactive shells. We reset GPG_AGENT_INFO so that we are sure it is not set and gpg, gpgsm, gpg-connect-agent can do the Right Thing. The test on $gnupg_SSH_AUTH_SOCK_by takes care of the case that gpg-agent has been started (for debugging) like this: $ GNUPGHOMEDIR=$(pwd) gpg-agent --daemon ~/bin/bash For 2.1 you even don't need to use use-standard-socket, because that is the configure default. gpg-agent will be started on demand. Because ssh does not know about this trick, it can't do that. Thus you need to call $ gpg-connect-agent /bye once to force starting a gpg-agent (I do that in my ~/.xession). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Fri Mar 22 17:27:25 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Fri, 22 Mar 2013 17:27:25 +0100 Subject: Hacking GPG-Agent In-Reply-To: <1363969019.4240.12.camel@e525.x-alina.name> References: <1363879613.4111.4.camel@e525.x-alina.name> <87k3ozsekn.fsf@vigenere.g10code.de> <1363969019.4240.12.camel@e525.x-alina.name> Message-ID: <1363969645.4240.16.camel@e525.x-alina.name> > killall gpg-agent > x-alina at e525:~$ cat ~/.gnupg/gpg-agent.conf > enable-ssh-support > use-standard-socket > x-alina at e525:~$ unset GPG_AGENT_INFO > x-alina at e525:~$ unset SSH_AGENT_PID > export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh" > x-alina at e525:~$ LANG=C gpg-connect-agent /bye > gpg-connect-agent: can't connect to the agent: IPC connect call failed > x-alina at e525:~$ pidof gpg-agent > x-alina at e525:~$ > > "gpg-connect-agent /bye" does not start the "gpg-agent" on my build. > (2.0.20-git6d0e418) But after this foobar I can run "gpg2 --card-status" and this will start the "gpg-agent", too. From wk at gnupg.org Fri Mar 22 20:38:37 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Mar 2013 20:38:37 +0100 Subject: scd: PC/SC cleanup In-Reply-To: <1363918774.3334.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 22 Mar 2013 11:19:34 +0900") References: <1363834188.2686.16.camel@cfw2.gniibe.org> <87sj3pw0dj.fsf@vigenere.g10code.de> <1363918774.3334.2.camel@cfw2.gniibe.org> Message-ID: <87sj3nql6q.fsf@vigenere.g10code.de> On Fri, 22 Mar 2013 03:19, gniibe at fsij.org said: > I tried. But sorry, the issue was not reported by me, thus, I don't > have privilege to add an comment to the issue on the BTS. Fixed. I just changed your role form Provisional User to User. The initial Provisional User role helps to avoid spam in existing reports. If anyone else has such problem, please drop me a note and I elevate your permissions. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lbastetti001 at gmail.com Sun Mar 24 16:44:43 2013 From: lbastetti001 at gmail.com (Ladislao Bastetti) Date: Sun, 24 Mar 2013 16:44:43 +0100 Subject: cannot compile gnupg-1.4.12 on 64bit distro Message-ID: Hi all, I'm trying to build gnupg-1.4.12 , on Debian Squeeze 64bit . I've read the open bug list , but I've not found anything similar , so I'm not sure if it is a bug . I'm following the procedure for installing the loop-AES, in the README section about gnupg there are some command lines to build gnupg with static linking , the line not working is : CFLAGS="-O2" LDFLAGS="-static -s" ./configure --prefix=/usr --enable-static-rnd=linux that gives the output .. checking for suffix of executables... checking whether we are cross compiling... unexpected reloc type in static binaryconfigure: error: in `/usr/src/gnupg-1.4.12': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details In the config.log (full config.log in attachment): ... configure:3668: $? = 0 configure:3657: gcc -v >&5 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) configure:3668: $? = 0 configure:3657: gcc -V >&5 gcc: '-V' option must have argument configure:3668: $? = 1 configure:3657: gcc -qversion >&5 gcc: unrecognized option '-qversion' gcc: no input files configure:3668: $? = 1 configure:3688: checking whether the C compiler works configure:3710: gcc -O2 -static -s conftest.c >&5 configure:3714: $? = 0 configure:3762: result: yes configure:3765: checking for C compiler default output file name configure:3767: result: a.out configure:3773: checking for suffix of executables configure:3780: gcc -o conftest -O2 -static -s conftest.c >&5 configure:3784: $? = 0 configure:3806: result: configure:3828: checking whether we are cross compiling configure:3836: gcc -o conftest -O2 -static -s conftest.c >&5 configure:3840: $? = 0 configure:3847: ./conftest ./configure: line 3849: 3980 Segmentation fault ./conftest$ac_cv_exeext configure:3851: $? = 139 configure:3858: error: in `/usr/src/gnupg-1.4.12': configure:3860: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details So, is this a bug , or my sistem is broken ? regards Ladislao -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: text/x-log Size: 9900 bytes Desc: not available URL: From wk at gnupg.org Sun Mar 24 18:47:25 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Mar 2013 18:47:25 +0100 Subject: cannot compile gnupg-1.4.12 on 64bit distro In-Reply-To: (Ladislao Bastetti's message of "Sun, 24 Mar 2013 16:44:43 +0100") References: Message-ID: <87ehf4pu4y.fsf@vigenere.g10code.de> On Sun, 24 Mar 2013 16:44, lbastetti001 at gmail.com said: > CFLAGS="-O2" LDFLAGS="-static -s" ./configure --prefix=/usr > --enable-static-rnd=linux If you use custom flags, you can't expect that it works as intended. Better don't do such stuff unless you have a enough experience to figure out the problem. Maybe some folks may want to help you anyway. BTW, do not pass envvars to the shell but pass them to configure like this: ./configure --prefix=/usr CFLAGS="-O2" LDFLAGS="-static -s" This allows configure to properly track them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Mar 25 05:33:11 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Mar 2013 13:33:11 +0900 Subject: scd: call update_card_removed only when detecting removal Message-ID: <1364185991.7215.2.camel@cfw2.gniibe.org> This is a change to SCDaemon to avoid unnecessary "learn" after card insertion. When we do: (1) insert card (2) run "gpg2 --card-status" (3) remove card (4) invoke "gpg2 --card-edit" (5) invoke some command like "verify" The step #5 fails (but with no message to user, this is another bug). This is because the function update_reader_status_file calls update_card_removed after the card is available. The thread of scd_update_reader_status_file, after "gpg2 --card-edit" was done by user, does not need to call the function, or rather, should not call the function. It the past, it should call the function (only) when the thread itself does do_reset for the card to let the application invoke "learn". In the past, the thread of scd_update_reader_status_file polls (at the period of 0.5 second) to detect card availability, so it is mostly this thread which calls do_reset. I think that this is the reason why this bug hasn't been caught. Still, this is a bug, because there is a race condition between the thread and an application thread. Now, the thread of scd_update_reader_status_file only polls for active card/token, and it is always an application thread which calls do_reset, any commands will fail. Built and tested for STABLE-BRANCH-2-0. Will do that for master, too. diff --git a/scd/command.c b/scd/command.c index e45153f..fc1f5a2 100644 --- a/scd/command.c +++ b/scd/command.c @@ -2310,10 +2310,8 @@ update_reader_status_file (int set_card_removed_flag) xfree (homestr); } - /* Set the card removed flag for all current sessions. We - will set this on any card change because a reset or - SERIALNO request must be done in any case. */ - if (ss->any && set_card_removed_flag) + /* Set the card removed flag for all current sessions. */ + if (ss->any && ss->status == 0 && set_card_removed_flag) update_card_removed (idx, 1); ss->any = 1; -- From lbastetti001 at gmail.com Mon Mar 25 07:15:25 2013 From: lbastetti001 at gmail.com (Ladislao Bastetti) Date: Mon, 25 Mar 2013 07:15:25 +0100 Subject: cannot compile gnupg-1.4.12 on 64bit distro In-Reply-To: <87ehf4pu4y.fsf@vigenere.g10code.de> References: <87ehf4pu4y.fsf@vigenere.g10code.de> Message-ID: Well, I'm not the author of the command line, as I said I'm only following the procedure to build gnupg as reported in loop-AES v 3.6g , without modification . Anyway , after more googling, it's a bug of Debian 64 bit , the bug #668257 : http://lists.debian.org/debian-gcc/2012/04/msg00099.html thanks anyway Ladislao 2013/3/24 Werner Koch > > On Sun, 24 Mar 2013 16:44, lbastetti001 at gmail.com said: > > > CFLAGS="-O2" LDFLAGS="-static -s" ./configure --prefix=/usr > > --enable-static-rnd=linux > > If you use custom flags, you can't expect that it works as intended. > Better don't do such stuff unless you have a enough experience to figure > out the problem. ?Maybe some folks may want to help you anyway. > > BTW, do not pass envvars to the shell but pass them to configure like > this: > > ? ./configure --prefix=/usr ?CFLAGS="-O2" LDFLAGS="-static -s" > > This allows configure to properly track them. > > > Salam-Shalom, > > ? ?Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From wk at gnupg.org Mon Mar 25 10:17:52 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Mar 2013 10:17:52 +0100 Subject: scd: call update_card_removed only when detecting removal In-Reply-To: <1364185991.7215.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Mon, 25 Mar 2013 13:33:11 +0900") References: <1364185991.7215.2.camel@cfw2.gniibe.org> Message-ID: <871ub3q1mn.fsf@vigenere.g10code.de> On Mon, 25 Mar 2013 05:33, gniibe at fsij.org said: > In the past, the thread of scd_update_reader_status_file polls (at the > period of 0.5 second) to detect card availability, so it is mostly > this thread which calls do_reset. I think that this is the reason why > this bug hasn't been caught. Still, this is a bug, because there is a Good catch. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Mar 26 01:13:36 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 Mar 2013 09:13:36 +0900 Subject: scd: PC/SC cleanup (more). Message-ID: <87ppynauhb.fsf@cfw2.gniibe.org> I applied following patch to both branches. scd: PC/SC cleanup (more). * scd/apdu.c (control_pcsc_direct, control_pcsc_wrapped, control_pcsc) (check_pcsc_pinpad, pcsc_pinpad_verify, pcsc_pinpad_modify): Use pcsc_dword_t. diff --git a/scd/apdu.c b/scd/apdu.c index 4734b12..d8f7c5f 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -1232,7 +1232,7 @@ pcsc_send_apdu (int slot, unsigned char *apdu, size_t apdulen, static int control_pcsc_direct (int slot, pcsc_dword_t ioctl_code, const unsigned char *cntlbuf, size_t len, - unsigned char *buffer, size_t *buflen) + unsigned char *buffer, pcsc_dword_t *buflen) { long err; @@ -1254,7 +1254,7 @@ control_pcsc_direct (int slot, pcsc_dword_t ioctl_code, static int control_pcsc_wrapped (int slot, pcsc_dword_t ioctl_code, const unsigned char *cntlbuf, size_t len, - unsigned char *buffer, size_t *buflen) + unsigned char *buffer, pcsc_dword_t *buflen) { long err = PCSC_E_NOT_TRANSACTED; reader_table_t slotp; @@ -1362,7 +1362,7 @@ control_pcsc_wrapped (int slot, pcsc_dword_t ioctl_code, static int control_pcsc (int slot, pcsc_dword_t ioctl_code, const unsigned char *cntlbuf, size_t len, - unsigned char *buffer, size_t *buflen) + unsigned char *buffer, pcsc_dword_t *buflen) { #ifdef NEED_PCSC_WRAPPER return control_pcsc_wrapped (slot, ioctl_code, cntlbuf, len, buffer, buflen); @@ -2027,7 +2027,7 @@ static int check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo) { unsigned char buf[256]; - size_t len = 256; + pcsc_dword_t len = 256; int sw; (void)pininfo; /* XXX: Identify reader and set pininfo->fixedlen. */ @@ -2088,7 +2088,7 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, unsigned char *pin_verify; int len = PIN_VERIFY_STRUCTURE_SIZE + pininfo->fixedlen; unsigned char result[2]; - size_t resultlen = 2; + pcsc_dword_t resultlen = 2; if (!reader_table[slot].atrlen && (sw = reset_pcsc_reader (slot))) @@ -2169,7 +2169,7 @@ pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, unsigned char *pin_modify; int len = PIN_MODIFY_STRUCTURE_SIZE + 2 * pininfo->fixedlen; unsigned char result[2]; - size_t resultlen = 2; + pcsc_dword_t resultlen = 2; if (!reader_table[slot].atrlen && (sw = reset_pcsc_reader (slot))) -- From gniibe at fsij.org Tue Mar 26 01:34:40 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 Mar 2013 09:34:40 +0900 Subject: Using OpenPGPcard through PC/SC service and with reader of Short APDU level exchange only Message-ID: <1364258080.2781.3.camel@cfw2.gniibe.org> Hello, I don't have the smartcard reader of "Short APDU level exchange only". If someone could test STABLE-BRANCH-2-0 with such reader(s), it is greatly appreciated. I'm looking the bug report: https://bugs.g10code.com/gnupg/issue1405 I guess that issue1105 issue1113 issue1114 would be by the same cause. I think that this bug could be solved, if we improve app-openpgp.c. During the development of Gnuk, I realized that smartcard related communication protocol is basically *broken*. Right Engineer tries to implement thinking the layer model and the abstraction, but it is impossible for smartcard. In case of OpenPGP card, the application needs to know if the reader supports extended APDU level exchange or not (in case of PC/SC service). Note that Gnuk 1.0.x is "Short APDU level exchange only", and it works well because its historical bytes specify no extended Lc and Le. -- From gniibe at fsij.org Tue Mar 26 04:54:40 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 Mar 2013 12:54:40 +0900 Subject: scd PC/SC status fix Message-ID: <87mwtqbytb.fsf@cfw2.gniibe.org> I applied following patch to both branches. I think that this is long standing bug. It is revealed by the change of update_reader_status_file. Built and tested. * scd/apdu.c (pcsc_get_status_direct): Check PCSC_STATE_MUTE only when PCSC_STATE_PRESENT. * scd/pcsc-wrapper.c (handle_status): Ditto. diff --git a/scd/apdu.c b/scd/apdu.c index d8f7c5f..4f40a69 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -914,9 +914,11 @@ pcsc_get_status_direct (int slot, unsigned int *status) *status = 0; if ( (rdrstates[0].event_state & PCSC_STATE_PRESENT) ) - *status |= APDU_CARD_PRESENT; - if ( !(rdrstates[0].event_state & PCSC_STATE_MUTE) ) - *status |= APDU_CARD_ACTIVE; + { + *status |= APDU_CARD_PRESENT; + if ( !(rdrstates[0].event_state & PCSC_STATE_MUTE) ) + *status |= APDU_CARD_ACTIVE; + } #ifndef HAVE_W32_SYSTEM /* We indicate a useful card if it is not in use by another application. This is because we only use exclusive access diff --git a/scd/pcsc-wrapper.c b/scd/pcsc-wrapper.c index 04d08a1..7d9415a 100644 --- a/scd/pcsc-wrapper.c +++ b/scd/pcsc-wrapper.c @@ -602,9 +602,11 @@ handle_status (unsigned char *argbuf, size_t arglen) if ( !(rdrstates[0].event_state & PCSC_STATE_UNKNOWN) ) { if ( (rdrstates[0].event_state & PCSC_STATE_PRESENT) ) - status |= 2; - if ( !(rdrstates[0].event_state & PCSC_STATE_MUTE) ) - status |= 4; + { + status |= 2; + if ( !(rdrstates[0].event_state & PCSC_STATE_MUTE) ) + status |= 4; + } /* We indicate a useful card if it is not in use by another application. This is because we only use exclusive access mode. */ -- From gniibe at fsij.org Fri Mar 29 02:11:09 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 29 Mar 2013 10:11:09 +0900 Subject: scd: move SCDaemon to libexecdir Message-ID: <87txnvf1si.fsf@cfw2.gniibe.org> Hello, I think that SCDaemon should not be in bindir, since it is not expected to be run as command line directly by any user (including developers who test it). When it's in bindir, it's just troublesome when user invokes it by the command line. Here is a change to move scdaemon to libexecdir (for STABLE-BRANCH-2-0). Built and tested. I think that this should be included for forthcoming 2.0.20. diff --git a/common/homedir.c b/common/homedir.c index 5f2e31e..d0fc5c6 100644 --- a/common/homedir.c +++ b/common/homedir.c @@ -410,7 +410,7 @@ gnupg_module_name (int which) #ifdef GNUPG_DEFAULT_SCDAEMON return GNUPG_DEFAULT_SCDAEMON; #else - X(bindir, "scdaemon"); + X(libexecdir, "scdaemon"); #endif case GNUPG_MODULE_NAME_DIRMNGR: diff --git a/scd/Makefile.am b/scd/Makefile.am index 58e2f9b..db339a2 100644 --- a/scd/Makefile.am +++ b/scd/Makefile.am @@ -17,9 +17,10 @@ ## Process this file with automake to produce Makefile.in -bin_PROGRAMS = scdaemon -if ! HAVE_W32_SYSTEM -libexec_PROGRAMS = gnupg-pcsc-wrapper +if HAVE_W32_SYSTEM +libexec_PROGRAMS = scdaemon +else +libexec_PROGRAMS = scdaemon gnupg-pcsc-wrapper endif EXTRA_DIST = ChangeLog-2011 -- From wk at gnupg.org Fri Mar 29 08:49:28 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Mar 2013 08:49:28 +0100 Subject: DCO for Werner Koch Message-ID: <87620ahchj.fsf@vigenere.g10code.de> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Werner Koch -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From wk at gnupg.org Fri Mar 29 09:01:23 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Mar 2013 09:01:23 +0100 Subject: scd: move SCDaemon to libexecdir In-Reply-To: <87txnvf1si.fsf@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 29 Mar 2013 10:11:09 +0900") References: <87txnvf1si.fsf@cfw2.gniibe.org> Message-ID: <871uayhbxo.fsf@vigenere.g10code.de> On Fri, 29 Mar 2013 02:11, gniibe at fsij.org said: > I think that SCDaemon should not be in bindir, since it is not expected > to be run as command line directly by any user (including developers who > test it). When it's in bindir, it's just troublesome when user invokes > it by the command line. You mean because scdaemon would than grab the reader and an instance started by gpg-agent won't be able to use the reader then? I think this is a good reason to move it to libexec. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Mar 29 09:24:01 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 29 Mar 2013 17:24:01 +0900 Subject: scd: move SCDaemon to libexecdir In-Reply-To: <871uayhbxo.fsf@vigenere.g10code.de> References: <87txnvf1si.fsf@cfw2.gniibe.org> <871uayhbxo.fsf@vigenere.g10code.de> Message-ID: <1364545441.14783.2.camel@cfw2.gniibe.org> On 2013-03-29 at 09:01 +0100, Werner Koch wrote: > On Fri, 29 Mar 2013 02:11, gniibe at fsij.org said: > > > I think that SCDaemon should not be in bindir, since it is not expected > > to be run as command line directly by any user (including developers who > > test it). When it's in bindir, it's just troublesome when user invokes > > it by the command line. > > You mean because scdaemon would than grab the reader and an instance > started by gpg-agent won't be able to use the reader then? I think this > is a good reason to move it to libexec. Yes, exactly. Sorry that I wasn't clear. I had a tutorial session for GnuPG and Gnuk Token the other day. I explained the relationship of gpg, gpg-agent, scdaemon, and pinentry. Then, I said that gpg-agent should be there (by login procedure of Xsession, or something. If not, invoke it). I didn't said how scdaemon is invoked and proceeded the tutorial. But some people thought that scdaemon should be there as well as gpg-daemon, and invoke it by their command line interface. Later, those people said that "I can't access Gnuk Token!". As I didn't expected people invoked scdaemon manually, it took some time to realize the situation. OK to apply? -- From wk at gnupg.org Fri Mar 29 11:39:18 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Mar 2013 11:39:18 +0100 Subject: scd: move SCDaemon to libexecdir In-Reply-To: <1364545441.14783.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 29 Mar 2013 17:24:01 +0900") References: <87txnvf1si.fsf@cfw2.gniibe.org> <871uayhbxo.fsf@vigenere.g10code.de> <1364545441.14783.2.camel@cfw2.gniibe.org> Message-ID: <87sj3efq21.fsf@vigenere.g10code.de> On Fri, 29 Mar 2013 09:24, gniibe at fsij.org said: > Yes, exactly. Sorry that I wasn't clear. I just wanted to state in also in my own words ;-) > OK to apply? Sure. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Fri Mar 29 12:00:32 2013 From: wking at tremily.us (W. Trevor King) Date: Fri, 29 Mar 2013 07:00:32 -0400 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <87620ahchj.fsf@vigenere.g10code.de> References: <87620ahchj.fsf@vigenere.g10code.de> Message-ID: <20130329110032.GM9945@odin.tremily.us> On Fri, Mar 29, 2013 at 08:49:28AM +0100, Werner Koch wrote: > GnuPG Developer's Certificate of Origin. Version 1.0 This looks like the Developer's Certificate of Origin 1.1 [1,2,3], with s/open source license/free software license/. Since free software licenses are presumably a subset of open source licenses, I don't understand the point of the change. The Linux project, for which the DCO was developed, is under the GPLv2 and they didn't see a need to make the free/open distinction. In the interest of avoiding DCO proliferation, it would be nice if we could avoid pointless changes. Do you think the change is meaningful? Cheers, Trevor [1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n309 [2]: https://git.kernel.org/cgit/git/git.git/tree/Documentation/SubmittingPatches#n217 [3]: https://github.com/wking/signed-off-by -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Mar 29 13:51:03 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Mar 2013 13:51:03 +0100 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <20130329110032.GM9945@odin.tremily.us> (W. Trevor King's message of "Fri, 29 Mar 2013 07:00:32 -0400") References: <87620ahchj.fsf@vigenere.g10code.de> <20130329110032.GM9945@odin.tremily.us> Message-ID: <87li96fjyg.fsf@vigenere.g10code.de> On Fri, 29 Mar 2013 12:00, wking at tremily.us said: > DCO proliferation, it would be nice if we could avoid pointless > changes. Do you think the change is meaningful? Yes, the GNU project prefers the term Free Software over the later coined term Open Source. For a detailed description see http://fsfe.org/documents/whyfs . Samba uses the more specific term GNU GPL but I don't want to use that because some parts of GnuPG are under a a mix of licenses. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Fri Mar 29 14:34:05 2013 From: wking at tremily.us (W. Trevor King) Date: Fri, 29 Mar 2013 09:34:05 -0400 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <87li96fjyg.fsf@vigenere.g10code.de> References: <87620ahchj.fsf@vigenere.g10code.de> <20130329110032.GM9945@odin.tremily.us> <87li96fjyg.fsf@vigenere.g10code.de> Message-ID: <20130329133405.GW9945@odin.tremily.us> On Fri, Mar 29, 2013 at 01:51:03PM +0100, Werner Koch wrote: > On Fri, 29 Mar 2013 12:00, wking at tremily.us said: > > DCO proliferation, it would be nice if we could avoid pointless > > changes. Do you think the change is meaningful? > > Yes, the GNU project prefers the term Free Software over the later > coined term Open Source. For a detailed description see > http://fsfe.org/documents/whyfs . Thanks for the pointer. Comparing the four features listed for free software: * run the program, for any purpose. * study how the program works, and adapt it to your needs. * redistribute copies. * improve the program, and release your improvements to the public, so that the whole community benefits. with the listed features for open source software [1], I don't see much of a distinction (but I'm not a lawyer). The original DCO avoids the need to define ?open source license? by qualifying it to mean ?the license indicated in the file being patched? or ?the open source license(s) involved?. I agree that if you were going to write a DCO from scratch, using ?free software? would be fine, but since the ?open source? version already exists, I don't see the point of changing it. Can you point me towards a license that qualifies as ?open source? but not as ?free software? (or vice versa)? Thanks, Trevor p.s. I like thinking about licenses, but I realize that this feeling is not universal ;). Feel free to tell me that the change is not open to discussion and I'll stop asking about it. [1]: http://opensource.org/docs/osd -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Mar 30 09:11:30 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 30 Mar 2013 09:11:30 +0100 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <20130329133405.GW9945@odin.tremily.us> (W. Trevor King's message of "Fri, 29 Mar 2013 09:34:05 -0400") References: <87620ahchj.fsf@vigenere.g10code.de> <20130329110032.GM9945@odin.tremily.us> <87li96fjyg.fsf@vigenere.g10code.de> <20130329133405.GW9945@odin.tremily.us> Message-ID: <87fvzdfgst.fsf@vigenere.g10code.de> On Fri, 29 Mar 2013 14:34, wking at tremily.us said: > is not universal ;). Feel free to tell me that the change is not open > to discussion and I'll stop asking about it. Using Open Source in a GNU context is a more severe sin that using Linux instead of GNU/Linux. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From x-alina at gmx.net Sat Mar 9 09:01:31 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Sat, 09 Mar 2013 08:01:31 -0000 Subject: Aw: Re: Pinpad support for REINER SCT cyberJack go Message-ID: An HTML attachment was scrubbed... URL: