scd: ambiguous certificate IDs for pkcs#15 certificates

Mario Haustein mario.haustein at hrz.tu-chemnitz.de
Mon Feb 19 16:33:02 CET 2024


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


More information about the Gnupg-devel mailing list