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.haust...@hrz.tu-chemnitz.de www.tu-chemnitz.de
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel