From mingli.yu at windriver.com Mon Feb 5 08:53:50 2024 From: mingli.yu at windriver.com (Yu, Mingli) Date: Mon, 5 Feb 2024 15:53:50 +0800 Subject: gnupg package version mismatch In-Reply-To: <874jf2k7fq.fsf@jacob.g10code.de> References: <87plxtk6by.fsf@jacob.g10code.de> <3d2d7443-3de5-b97f-050c-6604e2bc7a11@windriver.com> <1979652.usQuhbGJ8B@daneel> <874jf2k7fq.fsf@jacob.g10code.de> Message-ID: <0192bde9-65a2-49c5-8e1e-b1716dfaf9c8@windriver.com> On 1/25/24 00:44, Werner Koch via Gnupg-devel wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Wed, 24 Jan 2024 13:08, Ingo Kl?cker said: > >> openSUSE applies this patch >> https://build.opensuse.org/package/view_file/openSUSE:Factory/gpg2/gnupg-nobetasuffix.patch?expand=1 >> on their build system. > > Ahem. If you really must do that, go ahead. However, I would prefer if > you just replace the "-unknown" by "-windriver". And for Suse and other > distros who use modified versions to replace that by a string like > "-suse". This would help us a lot to evaluate bug reports. Could you help to provide one option to remove the -unknown suffix for the release version though we use git source. Thanks, > > > Salam-Shalom, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Mon Feb 5 10:52:41 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Feb 2024 10:52:41 +0100 Subject: gnupg package version mismatch In-Reply-To: <0192bde9-65a2-49c5-8e1e-b1716dfaf9c8@windriver.com> (Mingli via Gnupg-devel Yu's message of "Mon, 5 Feb 2024 15:53:50 +0800") References: <87plxtk6by.fsf@jacob.g10code.de> <3d2d7443-3de5-b97f-050c-6604e2bc7a11@windriver.com> <1979652.usQuhbGJ8B@daneel> <874jf2k7fq.fsf@jacob.g10code.de> <0192bde9-65a2-49c5-8e1e-b1716dfaf9c8@windriver.com> Message-ID: <87ttmnck5y.fsf@jacob.g10code.de> On Mon, 5 Feb 2024 15:53, Yu, Mingli said: > Could you help to provide one option to remove the > -unknown suffix for the release version though we use git source. Building production builds from git is not suggested. Create a tarball and build from that. That also helps to comply with the GPL requirements (hint: make distcheck). Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mario.haustein at hrz.tu-chemnitz.de Fri Feb 16 10:43:50 2024 From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein) Date: Fri, 16 Feb 2024 10:43:50 +0100 Subject: scd: ambiguous certificate IDs for pkcs#15 certificates Message-ID: <8375366.NyiUUSuA9g@localdomain> Dear developers, I am currently in the process of implementing the D-Trust ECC smartcards and encountered an issue in the certificate management for PKCS#15 cards. It is not limited to ECC cards and presumably concerns all PKCS#15 cards. When importing the keys and certificates from the smartcard, I get the following error: ``` $ gpgsm --learn-card gpgsm: dirmngr cache-only key lookup failed: No data gpgsm: issuer certificate {B01842AD4A24815A2A202C7DC4C0270C7CD07AE1} not found using authorityKeyIdentifier gpgsm: dirmngr cache-only key lookup failed: No data gpgsm: issuer certificate (#/CN=D-TRUST Limited Basic CA 1-4 2019,O=D-Trust GmbH,C=DE) not found [... much more similar lines for each certificate ...] ``` The card contains 2 keys and scdaemon reports 3 certificates for each key (root certificate, intermediate certificate, end user certificate). ``` $ ./scd/scdaemon --server scdaemon[12113]: NOTE: this is a development version! OK GNU Privacy Guard's Smartcard server ready learn scdaemon[12113]: detected reader 'Alcor Micro AU9540 00 00' S READER Alcor Micro AU9540 00 00 S SERIALNO 9276003211600214693F INQUIRE KNOWNCARDP 9276003211600214693F end S APPTYPE p15 S MANUFACTURER 0 D-TRUST GmbH (C) [D-Trust 4.1/4.4] S CERTINFO 100 P15-0104.02 Signaturzertifikat S CERTINFO 100 P15-0104.03 Authentisierungszertifikat S CERTINFO 101 P15-0104.02 Root-CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.02 CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.03 Root-CA-Zertifikat_fuer_Authentisierung S CERTINFO 101 P15-0104.03 CA-Zertifikat_fuer_Authentisierung S KEYPAIRINFO A45148C590655BA844A13F52D59105979BC93545 P15-0104.02 s 1682058347 rsa3072 S KEYPAIRINFO AF621109BA799E313088DD77F9732159EA9EE55F P15-0104.03 scea 1682058347 rsa3072 S CHV-STATUS 3 3 -2 S CHV-LABEL Card-PIN Card-PUK Signature-PIN OK ``` For this card, all certificates have the same ID tag for each key (2 or 3 in the example), as they are part of the same certificate chain. Thus the scdaemon certificate ID (P15-0104.02 and P15-0104.03 in the example) is not unique amongst all the certificates. When importing the certificate from the card, gpgsm issues a READCERT command which just returns the first matched certificate, but never the intermediate nor the root certificate. Is there a way to avoid this unambiguity? Would it for example be possible to use the path ID of the certificate file instead of the ID tag in the certificate descriptor? Is this mailinglist the right place to discuss this issue or should I open a task in the issue tracker? For completeness this is the content of the certificate directory object (path 3F00/0104/5101). ``` 30 SEQUENCE (53 bytes) 30 SEQUENCE (32 bytes) 0C UTF8String (26 bytes): Authentisierungszertifikat 03 BIT STRING (2 bytes): 10 30 SEQUENCE (3 bytes) 04 OCTET STRING (1 byte): 03 . A1 Context 1 (12 bytes) 30 SEQUENCE (10 bytes) 30 SEQUENCE (8 bytes) 04 OCTET STRING (6 bytes): 3F 00 01 03 02 04 ?..... 30 SEQUENCE (45 bytes) 30 SEQUENCE (24 bytes) 0C UTF8String (18 bytes): Signaturzertifikat 03 BIT STRING (2 bytes): 10 30 SEQUENCE (3 bytes) 04 OCTET STRING (1 byte): 02 . A1 Context 1 (12 bytes) 30 SEQUENCE (10 bytes) 30 SEQUENCE (8 bytes) 04 OCTET STRING (6 bytes): 3F 00 01 03 02 01 ?..... ``` This is the content of the additional certificate directory object (path 3F00/0104/5102). ``` 30 SEQUENCE (64 bytes) 30 SEQUENCE (40 bytes) 0C UTF8String (34 bytes): CA-Zertifikat fuer Authentisierung 03 BIT STRING (2 bytes): 10 30 SEQUENCE (6 bytes) 04 OCTET STRING (1 byte): 03 . 01 BOOLEAN (1 byte): true A1 Context 1 (12 bytes) 30 SEQUENCE (10 bytes) 30 SEQUENCE (8 bytes) 04 OCTET STRING (6 bytes): 3F 00 01 03 02 05 ?..... 30 SEQUENCE (69 bytes) 30 SEQUENCE (45 bytes) 0C UTF8String (39 bytes): Root-CA-Zertifikat fuer Authentisierung 03 BIT STRING (2 bytes): 10 30 SEQUENCE (6 bytes) 04 OCTET STRING (1 byte): 03 . 01 BOOLEAN (1 byte): true A1 Context 1 (12 bytes) 30 SEQUENCE (10 bytes) 30 SEQUENCE (8 bytes) 04 OCTET STRING (6 bytes): 3F 00 01 03 02 06 ?..... 30 SEQUENCE (57 bytes) 30 SEQUENCE (33 bytes) 0C UTF8String (27 bytes): CA-Zertifikat fuer Signatur 03 BIT STRING (2 bytes): 10 30 SEQUENCE (6 bytes) 04 OCTET STRING (1 byte): 02 . 01 BOOLEAN (1 byte): true A1 Context 1 (12 bytes) 30 SEQUENCE (10 bytes) 30 SEQUENCE (8 bytes) 04 OCTET STRING (6 bytes): 3F 00 01 03 02 02 ?..... 30 SEQUENCE (62 bytes) 30 SEQUENCE (38 bytes) 0C UTF8String (32 bytes): Root-CA-Zertifikat fuer Signatur 03 BIT STRING (2 bytes): 10 30 SEQUENCE (6 bytes) 04 OCTET STRING (1 byte): 02 . 01 BOOLEAN (1 byte): true A1 Context 1 (12 bytes) 30 SEQUENCE (10 bytes) 30 SEQUENCE (8 bytes) 04 OCTET STRING (6 bytes): 3F 00 01 03 02 03 ?..... ``` Kind regards -- Mario Haustein Facharbeitsgruppe Anwendungen Universit?tsrechenzentrum Technische Universit?t Chemnitz Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303) 09111 Chemnitz Germany Tel: +49 371 531-36606 Fax: +49 371 531-836606 mario.haustein at hrz.tu-chemnitz.de www.tu-chemnitz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From mario.haustein at hrz.tu-chemnitz.de Fri Feb 16 15:12:49 2024 From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein) Date: Fri, 16 Feb 2024 15:12:49 +0100 Subject: Key usage of ECC keys on PKCS#15 smartcards doesn't allow decryption? Message-ID: <2378092.NG923GbCHz@localdomain> Dear developers, while implementing the D-Trust ECC smartcards I encountered an issue I couldn't make sense of and would like to request assistance from you. I also couldn't find an issue in the bug tracker looking similar to it. My test cards provides two certificates: one for qualified signatures and one for (non-qualified) signatures and decryption. While the signature creation works out of the box for both keys, I am unable to decrypt an encrypted message with the latter key. This is the secret key: ID: 0x2F5CD959 S/N: 71440EE33409F4256085AFE32C15B5A6 (dec): 150556141664708457568253825304782812582 Issuer: /CN=D-TRUST Limited Basic Test CA 1-4 2020/O=D-Trust GmbH/C=DE Subject: /CN=XXX/C=DE/SerialNumber=DTR230045177P0004/SN=XXX/GN=XXX aka: XXX at d-trust.net validity: 2024-01-10 22:03:55 through 2026-01-20 22:03:55 key type: nistp256 key usage: digitalSignature keyAgreement ext key usage: emailProtection (suggested), clientAuth (suggested) policies: 1.3.6.1.4.1.4788.2.2.2:N: fingerprint: DF:30:3A:2E:C7:6E:60:FD:77:41:BA:03:86:F6:46:18:2F:5C:D9:59 sha2 fpr: 53:F5:22:23:CD:AD:52:7F:8A:B6:81:FD:C3:9D:04:0A: 7D:B8:48:7C:DF:B1:4D:84:84:D2:AA:C9:BE:19:BC:94 card s/n: 9276003211760004942F It supports the usage flags `sign` and `derive` reported as `digitalSignature` and `keyAgreement` in the frontend. I could narrow down the issue to `do_decipher()` in scd/app-p15.c. The function bails out at the following check. ``` if (!(prkdf->usageflags.decrypt || prkdf->usageflags.unwrap || prkdf->gpgusage.encr )) { log_error ("p15: key %s may not be used for decryption\n", keyidstr); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } ``` AFAIK decryption with ECDH keys is done by negotiating a common secret between Alice and Bob from which the symmetric encryption key is derived. So the `derive` key usage flag makes sense as the key is not capable of decrypting directly. When skipping this check, the smartcard works fine for decryption, too. Is it likely that the `derive` check was just forgotten at this place? I cannot judge the consequences of this change, which is the reason for asking here in advance. Many thanks in advance for reviewing my thoughts. Kind regards -- Mario Haustein Facharbeitsgruppe Anwendungen Universit?tsrechenzentrum Technische Universit?t Chemnitz Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303) 09111 Chemnitz Germany Tel: +49 371 531-36606 Fax: +49 371 531-836606 mario.haustein at hrz.tu-chemnitz.de www.tu-chemnitz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Sun Feb 18 17:46:11 2024 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Feb 2024 17:46:11 +0100 Subject: Key usage of ECC keys on PKCS#15 smartcards doesn't allow decryption? In-Reply-To: <2378092.NG923GbCHz@localdomain> (Mario Haustein via Gnupg-devel's message of "Fri, 16 Feb 2024 15:12:49 +0100") References: <2378092.NG923GbCHz@localdomain> Message-ID: <87sf1p7mb0.fsf@jacob.g10code.de> On Fri, 16 Feb 2024 15:12, Mario Haustein said: > Is it likely that the `derive` check was just forgotten at this place? I > cannot judge the consequences of this change, which is the reason for asking Well, not forgotten but I have never seen that used by cards. I'll check tomorrow whether I can see any problems with your suggestion. FWIW, in gpgsm we had a somewhat related problem with RSA cards: /* Telesec RSA cards produced for NRW in 2022 came with only the * keyAgreement bit set. This flag allows their use for encryption * anyway. Example cert: * Issuer: /CN=DOI CA 10a/OU=DOI/O=PKI-1-Verwaltung/C=DE * key usage: digitalSignature nonRepudiation keyAgreement * policies: 1.3.6.1.4.1.7924.1.1:N: */ #define COMPAT_ALLOW_KA_TO_ENCR 1 However, this was clearly wrong. Thanks for testing with the D-TRUST cards. I have had always problems working with the Bundesdruckerei ;-) Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Mon Feb 19 14:55:11 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Feb 2024 14:55:11 +0100 Subject: scd: ambiguous certificate IDs for pkcs#15 certificates In-Reply-To: <8375366.NyiUUSuA9g@localdomain> (Mario Haustein via Gnupg-devel's message of "Fri, 16 Feb 2024 10:43:50 +0100") References: <8375366.NyiUUSuA9g@localdomain> Message-ID: <875xyk7e4g.fsf@jacob.g10code.de> Hi Mario, > For this card, all certificates have the same ID tag for each key (2 or 3 in > the example), as they are part of the same certificate chain. Thus the I have not checked the specs but I think this is Bad Idea even if allowed. Clearly we will run into problems. > Is there a way to avoid this unambiguity? Would it for example be possible to > use the path ID of the certificate file instead of the ID tag in the This would not solve the case if we have several certificates in one record. My proposed solution is to add a counter if there is any duplicate id. For already supported cards this should not matter and the worst thing will be that the currently used IDs change - but they are anyway dynamically assigned. > Is this mailinglist the right place to discuss this issue or should I open a > task in the issue tracker? Sure. Here you get your audience. Nevertheless I also created https://dev.gnupg.org/T7001 for tracking. > 0C UTF8String (32 bytes): Root-CA-Zertifikat fuer Signatur Interesting that they provide the root CA's cert. I doubt that this is of any great help given that the verifier still needs to get that cert. And everyone needs to assign trust to that certificate anyway. Attached are two patches which I could not test. Please let me know whether they work for you. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-p15-Take-derive-usage-into-account-for-decryptio.patch Type: text/x-diff Size: 4150 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-scd-p15-Handle-duplicate-certificate-ids.patch Type: text/x-diff Size: 3790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mario.haustein at hrz.tu-chemnitz.de Mon Feb 19 16:33:02 2024 From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein) Date: Mon, 19 Feb 2024 16:33:02 +0100 Subject: scd: ambiguous certificate IDs for pkcs#15 certificates In-Reply-To: <875xyk7e4g.fsf@jacob.g10code.de> References: <8375366.NyiUUSuA9g@localdomain> <875xyk7e4g.fsf@jacob.g10code.de> Message-ID: <7003904.18pcnM708K@localdomain> Am Montag, 19. Februar 2024, 14:55:11 CET schrieb Werner Koch: > Hi Mario, Hi Werner, > > Is there a way to avoid this unambiguity? Would it for example be possible > > to use the path ID of the certificate file instead of the ID tag in the > > This would not solve the case if we have several certificates in one > record. My proposed solution is to add a counter if there is any > duplicate id. For already supported cards this should not matter and > the worst thing will be that the currently used IDs change - but they > are anyway dynamically assigned. your solution sounds much more simpler than mine and should solve the problem with record files as well. Maybe it's a good idea to separate the counter from the ID by an additional '.', isn't it? > > 0C UTF8String (32 bytes): Root-CA-Zertifikat fuer Signatur > > Interesting that they provide the root CA's cert. I doubt that this is > of any great help given that the verifier still needs to get that cert. > And everyone needs to assign trust to that certificate anyway. At least it shifts the problem from getting the root certificate to just verifying the fingerprint of the root certificate. The latter approach is more robust for end-users IMHO. > Attached are two patches which I could not test. Please let me know > whether they work for you. Thanks for solving the key usage problem as well. I will respond to it in the other thread. The tie-breaking of the PKCS#15 IDs only works partially. This is the output of scdaemon: ``` $ ./scd/scdaemon --server scdaemon[29915]: NOTE: this is a development version! OK GNU Privacy Guard's Smartcard server ready learn scdaemon[29915]: detected reader 'Alcor Micro AU9540 00 00' S READER Alcor Micro AU9540 00 00 S SERIALNO 9276003211760004942F INQUIRE KNOWNCARDP 9276003211760004942F end S APPTYPE p15 S MANUFACTURER 0 D-TRUST GmbH (C) [D-Trust 4.1/4.4] S CERTINFO 100 P15-0104.02 Signaturzertifikat S CERTINFO 100 P15-0104.03 Authentisierungszertifikat S CERTINFO 101 P15-0104.0202 Root-CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.02 CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.0301 Root-CA-Zertifikat_fuer_Authentisierung S CERTINFO 101 P15-0104.03 CA-Zertifikat_fuer_Authentisierung S KEYPAIRINFO 0A3C46CED17CF02AF533EAD70D5211D0B6175C50 P15-0104.02 s 1704924235 nistp256 S KEYPAIRINFO C76DB72791417F11B221466C762041EAE5A383E7 P15-0104.03 scea 1704924235 nistp256 S CHV-STATUS 3 3 -2 S CHV-LABEL Card-PIN Card-PUK Signature-PIN OK killscd OK closing connection ``` I expected something like ``` S CERTINFO 100 P15-0104.02 Signaturzertifikat S CERTINFO 100 P15-0104.03 Authentisierungszertifikat S CERTINFO 101 P15-0104.0202 Root-CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.0201 CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.0302 Root-CA-Zertifikat_fuer_Authentisierung S CERTINFO 101 P15-0104.0301 CA-Zertifikat_fuer_Authentisierung ``` or maybe ``` S CERTINFO 100 P15-0104.02 Signaturzertifikat S CERTINFO 100 P15-0104.03 Authentisierungszertifikat S CERTINFO 101 P15-0104.0204 Root-CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.0203 CA-Zertifikat_fuer_Signatur S CERTINFO 101 P15-0104.0302 Root-CA-Zertifikat_fuer_Authentisierung S CERTINFO 101 P15-0104.0301 CA-Zertifikat_fuer_Authentisierung ``` It seems the counter is application-global, but collision detection is just scoped to the object directory. This leads to the following result in gpgsm. ``` $ gpgsm -k ID: 0x2F5CD959 S/N: 71440EE33409F4256085AFE32C15B5A6 (dec): 150556141664708457568253825304782812582 Issuer: /CN=D-TRUST Limited Basic Test CA 1-4 2020/O=D-Trust GmbH/C=DE Subject: /CN=XXX/C=DE/SerialNumber=DTR230045177P0004/SN=XXX/GN=XXX aka: XXX at d-trust.net validity: 2024-01-10 22:03:55 through 2026-01-20 22:03:55 key type: nistp256 key usage: digitalSignature keyAgreement ext key usage: emailProtection (suggested), clientAuth (suggested) policies: 1.3.6.1.4.1.4788.2.2.2:N: fingerprint: DF:30:3A:2E:C7:6E:60:FD:77:41:BA:03:86:F6:46:18:2F:5C:D9:59 sha2 fpr: 53:F5:22:23:CD:AD:52:7F:8A:B6:81:FD:C3:9D:04:0A: 7D:B8:48:7C:DF:B1:4D:84:84:D2:AA:C9:BE:19:BC:94 ID: 0x405CBC84 S/N: 598037FE594FA009D068DD6112B5DFC8 (dec): 118967041306871876863430516748464807880 Issuer: /CN=D-TRUST Limited Basic Root Test CA 1 2020/O=D-Trust GmbH/ C=DE Subject: /CN=D-TRUST Limited Basic Root Test CA 1 2020/O=D-Trust GmbH/ C=DE validity: 2020-06-09 07:10:03 through 2035-06-09 07:10:02 key type: nistp384 key usage: certSign crlSign chain length: unlimited fingerprint: DC:5C:5D:CF:FD:37:BC:EA:C5:9E:6A:E0:89:EE:A2:AC:40:5C:BC:84 sha2 fpr: 45:AF:68:34:BC:D2:9F:5C:23:9E:8C:CB:4A:50:24:BD: 21:84:16:B4:71:A7:AB:DF:88:43:C5:EC:5F:13:A1:6E ID: 0x63A8164F S/N: 669A54788A9E0F55CFC9EFDE87D1E6CB (dec): 136382582558962004996306121756500944587 Issuer: /CN=D-TRUST Test CA 2-21-1 2021/O=D-Trust GmbH/C=DE/ 2.5.4.97=NTRDE-HRB74346 Subject: /CN=XXX/C=DE/SerialNumber=DTR230045177P0004/SN=XXX/GN=XXX validity: 2024-01-10 22:03:55 through 2026-01-20 22:03:55 key type: nistp256 key usage: nonRepudiation policies: 1.3.6.1.4.1.4788.2.2.2:N: fingerprint: FA:16:39:66:94:1C:E0:14:01:57:26:6C:42:98:F6:D8:63:A8:16:4F sha2 fpr: 80:DB:32:D7:10:29:F7:59:5A:FF:C9:12:EE:EF:8B: 0F:A4:F8:05:20:E5:99:AC:43:78:1C:D7:67:9C:C2:0F:E5 ID: 0x757E834D S/N: 6739E37C35FADA1E90F5C1C72278B173 (dec): 137211058434760967797058464826942599539 Issuer: /CN=D-TRUST Root Test CA 2 2021/O=D-Trust GmbH/C=DE Subject: /CN=D-TRUST Root Test CA 2 2021/O=D-Trust GmbH/C=DE validity: 2021-02-02 12:31:20 through 2036-02-10 08:31:20 key type: nistp384 key usage: certSign crlSign chain length: unlimited fingerprint: 5B:02:E0:14:07:81:9B:17:F6:12:F7:16:84:4D:CD:47:75:7E:83:4D sha2 fpr: 90:A5:9D:40:1D:53:25:A0:1D:98:E5:84:16:E8:5F:35:80:1A:13:2F: 6A:F5:F6:69:21:4E:C2:29:4F:18:80:9B ``` The intermediate certificate is missing as the IDs are still clashing at this point. Maybe you will find a solution. But I will think about it as well. Kind regards -- Mario Haustein Facharbeitsgruppe Anwendungen Universit?tsrechenzentrum Technische Universit?t Chemnitz Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303) 09111 Chemnitz Germany Tel: +49 371 531-36606 Fax: +49 371 531-836606 mario.haustein at hrz.tu-chemnitz.de www.tu-chemnitz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From mario.haustein at hrz.tu-chemnitz.de Mon Feb 19 16:47:22 2024 From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein) Date: Mon, 19 Feb 2024 16:47:22 +0100 Subject: Key usage of ECC keys on PKCS#15 smartcards doesn't allow decryption? In-Reply-To: <87sf1p7mb0.fsf@jacob.g10code.de> References: <2378092.NG923GbCHz@localdomain> <87sf1p7mb0.fsf@jacob.g10code.de> Message-ID: <5460453.29KlJPOoH8@localdomain> Hi Werner, Am Sonntag, 18. Februar 2024, 17:46:11 CET schrieb Werner Koch: > On Fri, 16 Feb 2024 15:12, Mario Haustein said: > > Is it likely that the `derive` check was just forgotten at this place? I > > cannot judge the consequences of this change, which is the reason for > > asking > Well, not forgotten but I have never seen that used by cards. I'll > check tomorrow whether I can see any problems with your suggestion. > > FWIW, in gpgsm we had a somewhat related problem with RSA cards: > > /* Telesec RSA cards produced for NRW in 2022 came with only the > * keyAgreement bit set. This flag allows their use for encryption > * anyway. Example cert: > * Issuer: /CN=DOI CA 10a/OU=DOI/O=PKI-1-Verwaltung/C=DE > * key usage: digitalSignature nonRepudiation keyAgreement > * policies: 1.3.6.1.4.1.7924.1.1:N: > */ > #define COMPAT_ALLOW_KA_TO_ENCR 1 > > However, this was clearly wrong. Thanks for testing with the D-TRUST > cards. I have had always problems working with the Bundesdruckerei ;-) thanks for your patch in the PKCS#15 object ID mail thread. I applied it and can confirm, it solves the problem. I worked independently on this topic and came to a similar solution which just differs in a detail. I was wondering why the derive key usage was not considered in do_getattr(). Is there a specific reason for it? From my understanding it should allow to use the card for OpenPGP keys as well. You will find my patch as nr. 0003 in the patchset together with my preliminary patch for the ECC cards (and a typo). I omitted the patch for the PKCS#15 object ID problem, as there are still issues to solve. If all the issues are solve, I will prepare a final patchset. Kind regards -- Mario Haustein Facharbeitsgruppe Anwendungen Universit?tsrechenzentrum Technische Universit?t Chemnitz Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303) 09111 Chemnitz Germany Tel: +49 371 531-36606 Fax: +49 371 531-836606 mario.haustein at hrz.tu-chemnitz.de www.tu-chemnitz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-p15-Take-derive-usage-into-account-for-decryptio.patch Type: text/x-patch Size: 4151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-scd-p15-Take-derive-usage-into-account-for-decryptio.patch Type: text/x-patch Size: 1536 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-scd-p15-Fix-typo-in-a-comment.patch Type: text/x-patch Size: 877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-scd-p15-Add-ECC-support-for-D-Trust-Card-4.1-4.4.patch Type: text/x-patch Size: 1558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Feb 19 16:53:04 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Feb 2024 16:53:04 +0100 Subject: scd: ambiguous certificate IDs for pkcs#15 certificates In-Reply-To: <7003904.18pcnM708K@localdomain> (Mario Haustein via Gnupg-devel's message of "Mon, 19 Feb 2024 16:33:02 +0100") References: <8375366.NyiUUSuA9g@localdomain> <875xyk7e4g.fsf@jacob.g10code.de> <7003904.18pcnM708K@localdomain> Message-ID: <871q9878nz.fsf@jacob.g10code.de> On Mon, 19 Feb 2024 16:33, Mario Haustein said: > your solution sounds much more simpler than mine and should solve the problem > with record files as well. Maybe it's a good idea to separate the counter from > the ID by an additional '.', isn't it? Much more work and code unfortunately. > At least it shifts the problem from getting the root certificate to just > verifying the fingerprint of the root certificate. The latter approach is more > robust for end-users IMHO. Right. > It seems the counter is application-global, but collision detection is just > scoped to the object directory. Good attach. Please add the attached patch. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-p15-Check-all-cert-stores-for-dups.patch Type: text/x-diff Size: 1353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mario.haustein at hrz.tu-chemnitz.de Mon Feb 19 17:48:12 2024 From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein) Date: Mon, 19 Feb 2024 17:48:12 +0100 Subject: scd: ambiguous certificate IDs for pkcs#15 certificates In-Reply-To: <871q9878nz.fsf@jacob.g10code.de> References: <8375366.NyiUUSuA9g@localdomain> <7003904.18pcnM708K@localdomain> <871q9878nz.fsf@jacob.g10code.de> Message-ID: <2947892.o0KrE1Onz3@localdomain> Hi Werner, Am Montag, 19. Februar 2024, 16:53:04 CET schrieb Werner Koch: > > It seems the counter is application-global, but collision detection is > > just > > scoped to the object directory. > > Good attach. Please add the attached patch. many thanks! This was really fast. Now it works perfectly. I will prepare a final patchset with all the patches for the D-Trust ECC cards. Kind Regards Mario -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From mario.haustein at hrz.tu-chemnitz.de Mon Feb 19 18:00:54 2024 From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein) Date: Mon, 19 Feb 2024 18:00:54 +0100 Subject: [PATCH GnuPG 0/5] Add ECC support for D-Trust 4.1/4.4 Message-ID: <3378651.usfYGdeWWP@localdomain> Dear Developers, this series of patches adds ECC support for the D-Trust 4.1/4.4 cards. All the code was already there. Just the security environment parameters had to be confirmed which I now successfully did with my test cards. The patches further allow keys with the derive usage-flag to be used for decryption and fixes certificate import for duplicate certificate IDs. These issues were already addressed in separate threads on this list. I am unsure whether patch nr. 0003 is necessary. Feel free to either omit it or to squash it with 0002. Mario Haustein (3): scd:p15: Take derive usage into account for decryption. scd:p15: Fix typo in a comment scd:p15: Add ECC support for D-Trust Card 4.1/4.4 Werner Koch (2): scd:p15: Handle duplicate certificate ids. scd:p15: Take derive usage into account for decryption. scd/app-p15.c | 96 +++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 71 insertions(+), 25 deletions(-) -- 2.43.0 Kind regards -- Mario Haustein Facharbeitsgruppe Anwendungen Universit?tsrechenzentrum Technische Universit?t Chemnitz Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303) 09111 Chemnitz Germany Tel: +49 371 531-36606 Fax: +49 371 531-836606 mario.haustein at hrz.tu-chemnitz.de www.tu-chemnitz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-p15-Handle-duplicate-certificate-ids.patch Type: text/x-patch Size: 4173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-scd-p15-Take-derive-usage-into-account-for-decryptio.patch Type: text/x-patch Size: 4151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-scd-p15-Fix-typo-in-a-comment.patch Type: text/x-patch Size: 877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-scd-p15-Take-derive-usage-into-account-for-decryptio.patch Type: text/x-patch Size: 1536 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-scd-p15-Add-ECC-support-for-D-Trust-Card-4.1-4.4.patch Type: text/x-patch Size: 1558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Feb 20 09:36:26 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2024 09:36:26 +0100 Subject: Key usage of ECC keys on PKCS#15 smartcards doesn't allow decryption? In-Reply-To: <5460453.29KlJPOoH8@localdomain> (Mario Haustein via Gnupg-devel's message of "Mon, 19 Feb 2024 16:47:22 +0100") References: <2378092.NG923GbCHz@localdomain> <87sf1p7mb0.fsf@jacob.g10code.de> <5460453.29KlJPOoH8@localdomain> Message-ID: <87wmqz5y7p.fsf@jacob.g10code.de> On Mon, 19 Feb 2024 16:47, Mario Haustein said: > came to a similar solution which just differs in a detail. I was wondering why > the derive key usage was not considered in do_getattr(). Is there a specific > reason for it? From my understanding it should allow to use the card for Oversight. Fixed in the original pacth. I pushed those two. > If all the issues are solve, I will prepare a final patchset. I noticed the other mail. Will check it soon. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 20 10:34:11 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2024 10:34:11 +0100 Subject: [PATCH GnuPG 0/5] Add ECC support for D-Trust 4.1/4.4 In-Reply-To: <3378651.usfYGdeWWP@localdomain> (Mario Haustein via Gnupg-devel's message of "Mon, 19 Feb 2024 18:00:54 +0100") References: <3378651.usfYGdeWWP@localdomain> Message-ID: <87o7cb5vjg.fsf@jacob.g10code.de> Hi! On Mon, 19 Feb 2024 18:00, Mario Haustein said: > I am unsure whether patch nr. 0003 is necessary. Feel free to either omit it I applied the part which I had not done in the other patch. > scd:p15: Add ECC support for D-Trust Card 4.1/4.4 Applied and pushed. Many thanks. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From falko.strenzke at mtg.de Wed Feb 21 11:01:54 2024 From: falko.strenzke at mtg.de (Falko Strenzke) Date: Wed, 21 Feb 2024 11:01:54 +0100 Subject: Bug in g10/build-packet.c:gpg_mpi_write() Message-ID: <303d5816-8df7-466c-8389-52524e58baba@mtg.de> Hi, I think there is a bug in GnuPG the function g10/build-packet.c:gpg_mpi_write() The case I observed is an opaque MPI with a leading byte 0x04. The call to gcry_mpi_get_opaque() already sets the correct bit length (i.e. accounting for the highest 5 bits to be zero). Then the subsequent code again subtracts 5 from nbits, effectively reducing the byte count by one. The written MPI is thus one byte too short. - Falko gpg_error_t gpg_mpi_write (iobuf_t out, gcry_mpi_t a, unsigned int *r_nwritten) { ? gpg_error_t err; ? unsigned int nwritten = 0; ? if (gcry_mpi_get_flag (a, GCRYMPI_FLAG_OPAQUE)) ??? { ????? unsigned int nbits; ????? const unsigned char *p; ????? unsigned char lenhdr[2]; ????? /* gcry_log_debugmpi ("a", a); */ ????? p = gcry_mpi_get_opaque (a, &nbits); ????? if (p) ??????? { ????????? /* Strip leading zero bits.? */ ????????? for (; nbits >= 8 && !*p; p++, nbits -= 8) ??????????? ; ????????? if (nbits >= 8 && !(*p & 0x80)) ??????????? if (--nbits >= 7 && !(*p & 0x40)) ????????????? if (--nbits >= 6 && !(*p & 0x20)) ??????????????? if (--nbits >= 5 && !(*p & 0x10)) ????????????????? if (--nbits >= 4 && !(*p & 0x08)) ??????????????????? if (--nbits >= 3 && !(*p & 0x04)) ????????????????????? if (--nbits >= 2 && !(*p & 0x02)) ??????????????????????? if (--nbits >= 1 && !(*p & 0x01)) ????????????????????????? --nbits; -- *MTG AG* Dr. Falko Strenzke Executive System Architect Phone: +49 6151 8000 24 E-Mail: falko.strenzke at mtg.de Web: mtg.de MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany Commercial register: HRB 8901 Register Court: Amtsgericht Darmstadt Management Board: J?rgen Ruf (CEO), Tamer Kemer?z Chairman of the Supervisory Board: Dr. Thomas Milde This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted. Data protection information: Privacy policy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4813 bytes Desc: Kryptografische S/MIME-Signatur URL: From wk at gnupg.org Wed Feb 21 16:25:26 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Feb 2024 16:25:26 +0100 Subject: Bug in g10/build-packet.c:gpg_mpi_write() In-Reply-To: <303d5816-8df7-466c-8389-52524e58baba@mtg.de> (Falko Strenzke's message of "Wed, 21 Feb 2024 11:01:54 +0100") References: <303d5816-8df7-466c-8389-52524e58baba@mtg.de> Message-ID: <87bk894z6h.fsf@jacob.g10code.de> Hi! > call to gcry_mpi_get_opaque() already sets the correct bit length > (i.e. accounting for the highest 5 bits to be zero). Then the > subsequent code again subtracts 5 from nbits, effectively reducing the Good catch and my fault from 2015. That code is not anymore used because we switched to sos_write for ECC parameters in 2020. However, in theory GnuPG versions 2.1.5 to 2.2.20 may have produced produced incorrect MPIs when writing ECC parameters. Fortunately the mpi read function has always rounded up to full bytes, the gcry_sexp_nth_mpi, used to parse the s-expressions, either produced a plain MPI or when requested to create an opaque MPI, the bit value was also rounded up to full bytes. > byte count by one. The written MPI is thus one byte too short. I am pretty sure this would have been noticed ;-) Fixed with: https://dev.gnupg.org/rG2372f6a4035cefd5ac1852e95dc50de89cc73af6 Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From vollkorn at cryptobitch.de Mon Feb 26 15:29:21 2024 From: vollkorn at cryptobitch.de (Jan Girlich) Date: Mon, 26 Feb 2024 15:29:21 +0100 Subject: SKS-Keyserver returns negative timestamp Message-ID: <53ad9d45e89e72c48aad87b957b3db569045cfaa.camel@cryptobitch.de> Hi, I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and receive the following response: 'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::' How is the timestamp '-62135596800' to be interpreted? I looked up the RFC for the HKP and it states quite clearly, that this field should be seconds since 01.01.1970: https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp-00#section-5.2 Respectively: https://datatracker.ietf.org/doc/html/rfc2440#section-3.5 How come the SKS server returns a negative timestamp then? Cheers, Jan From kolya007.klass at gmail.com Mon Feb 26 17:03:33 2024 From: kolya007.klass at gmail.com (Evangeline Rome) Date: Mon, 26 Feb 2024 19:03:33 +0300 Subject: Help with account creation Message-ID: Hi, dear devs! Sorry if this is not the right channel of communication, but I really haven't found any more appropriate where I have the rights to speak. I tried to create an account on dev.gnupg.org, but all my attempts to create an account were banned without any reason. I tried to create it with github account and with this google email. Can anybody suggest me more appropriate channel where to ask about this? Or if I'm in the right place please unban me (I'm human, trust me). My nickname is `nikelborm` and email is `kolya007.klass at gmail.com` Best regards, Eva -------------- next part -------------- An HTML attachment was scrubbed... URL: From vollkorn at cryptobitch.de Mon Feb 26 18:19:50 2024 From: vollkorn at cryptobitch.de (Jan Girlich) Date: Mon, 26 Feb 2024 18:19:50 +0100 Subject: SKS-Keyserver returns negative timestamp Message-ID: Hi, I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and receive the following response: 'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::' How is the timestamp '-62135596800' to be interpreted? I looked up the RFC for the HKP and it states quite clearly, that this field should be seconds since 01.01.1970: https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp-00#section-5.2 Respectively: https://datatracker.ietf.org/doc/html/rfc2440#section-3.5 How come the SKS server returns a negative timestamp then? Cheers, Jan _______________________________________________ Gnupg-devel mailing list Gnupg-devel at gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel From vollkorn at cryptobitch.de Mon Feb 26 18:42:00 2024 From: vollkorn at cryptobitch.de (Jan Girlich) Date: Mon, 26 Feb 2024 18:42:00 +0100 Subject: SKS-Keyserver returns negative timestamp In-Reply-To: References: <53ad9d45e89e72c48aad87b957b3db569045cfaa.camel@cryptobitch.de> Message-ID: <9d2a95e84ac1cf3551857e127880bb405d09d1a8.camel@cryptobitch.de> Hi Andrew, On Mon, 2024-02-26 at 17:14 +0000, Andrew Gallagher wrote: > On 26 Feb 2024, at 14:29, Jan Girlich > wrote: > > > > I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and > > receive > > the following response: > > > > 'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::' > > > > How is the timestamp '-62135596800' to be interpreted? > > It would normally be interpreted as ?seconds before the epoch?, but > in this particular case the key is unparseable, so the number is > meaningless. Keys can be unparseable for many reasons, but the most > common one is the use of an obsolete primary key algorithm, such as > RSA512 or Elgamal encrypt-and-sign. thanks for this explanation. I know that this key worked fine from the same keyserver before. Should I be worried about the integrity of the web of trust with regard to corrupted keys? Or could it be that since this key has been revoked that the keyserver is giving nonsensical responses on purpose? Cheers, Jan From andrewg at andrewg.com Mon Feb 26 18:14:58 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 26 Feb 2024 17:14:58 +0000 Subject: SKS-Keyserver returns negative timestamp In-Reply-To: <53ad9d45e89e72c48aad87b957b3db569045cfaa.camel@cryptobitch.de> References: <53ad9d45e89e72c48aad87b957b3db569045cfaa.camel@cryptobitch.de> Message-ID: On 26 Feb 2024, at 14:29, Jan Girlich wrote: > > I am doing a request to an SKS keyserver (sks.pgpkeys.eu) and receive > the following response: > > 'pub:AC71EF0964192842B15AFE6417EDE60510000001:0:0:-62135596800::' > > How is the timestamp '-62135596800' to be interpreted? It would normally be interpreted as ?seconds before the epoch?, but in this particular case the key is unparseable, so the number is meaningless. Keys can be unparseable for many reasons, but the most common one is the use of an obsolete primary key algorithm, such as RSA512 or Elgamal encrypt-and-sign. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From andrewg at andrewg.com Mon Feb 26 19:36:05 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 26 Feb 2024 18:36:05 +0000 Subject: SKS-Keyserver returns negative timestamp In-Reply-To: <9d2a95e84ac1cf3551857e127880bb405d09d1a8.camel@cryptobitch.de> References: <53ad9d45e89e72c48aad87b957b3db569045cfaa.camel@cryptobitch.de> <9d2a95e84ac1cf3551857e127880bb405d09d1a8.camel@cryptobitch.de> Message-ID: On 26 Feb 2024, at 17:42, Jan Girlich wrote: > > On Mon, 2024-02-26 at 17:14 +0000, Andrew Gallagher wrote: >> On 26 Feb 2024, at 14:29, Jan Girlich >> wrote: >>> >>> How is the timestamp '-62135596800' to be interpreted? >> >> It would normally be interpreted as ?seconds before the epoch?, but >> in this particular case the key is unparseable, so the number is >> meaningless. Keys can be unparseable for many reasons, but the most >> common one is the use of an obsolete primary key algorithm, such as >> RSA512 or Elgamal encrypt-and-sign. > > thanks for this explanation. I know that this key worked fine from the > same keyserver before. This was most likely before it was migrated from sks-keyserver to hockeypuck, about three(?) years ago. > Should I be worried about the integrity of the > web of trust with regard to corrupted keys? Or could it be that since > this key has been revoked that the keyserver is giving nonsensical > responses on purpose? So, for a bit of context, epoch minus 62135596800 is 1 Jan 0001. This is the default ?zero time? in golang, meaning that any uninitialised timestamp variable will return this value. The expiry time for this key is uninitialised because there are no valid self-signatures over this key, which in turn is because it is an RSA1024 key, which is no longer supported by go-crypto/openpgp and therefore its signatures are unparseable by hockeypuck. In a sense, it is ?not even revoked?. Any WoT certifications made by this key are no longer cryptographically sound and should not be relied upon. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bernhard at intevation.de Tue Feb 27 09:29:01 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 27 Feb 2024 09:29:01 +0100 Subject: dev.gnupg.org account creation (Re: Help with account creation) In-Reply-To: References: Message-ID: <202402270929.10941.bernhard@intevation.de> Hi Eva, this is the right place to ask about dev.gnupg.org accounts. Am Montag 26 Februar 2024 17:03:33 schrieb Evangeline Rome via Gnupg-devel: > I tried to create an account on dev.gnupg.org, but all my attempts to create > an account were banned without any reason. What did you experience in detail (any messages?) I think accounts have to be manually approved, maybe this hasn't happened yet? > I tried to create it with github account and with this google email. It should work. I think admins may contact you. Best, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Feb 27 10:48:47 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Feb 2024 10:48:47 +0100 Subject: Help with account creation In-Reply-To: (Evangeline Rome via Gnupg-devel's message of "Mon, 26 Feb 2024 19:03:33 +0300") References: Message-ID: <87bk821bls.fsf@jacob.g10code.de> Hi! On Mon, 26 Feb 2024 19:03, Evangeline Rome said: > Sorry if this is not the right channel of communication, but I really > haven't found any more appropriate where I have the rights to speak. I You found the right place. Unfortunately more far more than 90% off all registered accounts are fraudulent and we use some kind of ad-hoc heuristics to decide which we can approve and which are far more likely spammers. Spammers are then disabled and we hope that false positives get in touch with you. I just re-enabled and approved your account. Sorry for the inconveninece, and yes, we should give Github accounts a higher credibility. The web interface unfortunately does not show this information. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: