scd: ambiguous certificate IDs for pkcs#15 certificates

Fri Feb 16 10:43:50 CET 2024

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240216/4c5c79fb/attachment-0001.sig>