Mailing List Archive

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

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@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@hrz.tu-chemnitz.de
www.tu-chemnitz.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

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