In 3.4, Yubikey has a specific feature of "Attestation key".
This would cause compatibility issue with GnuPG, so, we need to care about the "Attestation key" (even if it won't be supported by standard tool).
Description
Revisions and Commits
| rG GnuPG | |||
| rGe285b1197b93 scd: Fix condition for C5 data object for newer Yubikey. | |||
| rGf3df8dbb696f scd: Fix condition for C5 data object for newer Yubikey. | |||
Event Timeline
Here is the dump of "Application Related Data" (6E):
6e 82 01 47
4f 10
d2760001240103040006106160490000
5f 52 08
00730000e0059000
7f 74 03
810120
73 82 01 20
c0 0a
7d000bfe080000ff0000
c1 0b
162b06010401da470f0100
c2 0c
122b06010401975501050100
c3 0b
162b06010401da470f0100
da 06 <-------------------------------------- This is algorithm attributes for Attestation key (Yubikey specific)
010800001100
c4 07
ff7f7f7f030003
c5 50
eeeed1b50b1b1d9c669033fe019e94a27992b44c
d00b630fdcb5c4397d5ffbd69aa68a3ff9f8ed10
1b2a3d46f4f0c5afd0115e7eb858d476daf64cdb
0000000000000000000000000000000000000000 <--- This appears to be fingerprint of Attestation key
c6 50
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000 <--- This appears to be fingerprint of some key related to Attestation key???
cd 10
5e58b1e65e58b1c55e58b1f900000000
de 08
0102020203028102
7f 66 08
02020bfe02020bfe
d6 02
0020
d7 02
0020
d8 02
0020
d9 02
0020And here is (raw) dump of the data object FA:
raw apdu: 00ca00fa00
response: sw=61E4 datalen=256
dump: fa8201e2c106010800001100c106010c00001100c106011000001100c109132a \
8648ce3d030107c106132b81040022c106132b81040023c106132b8104000ac1 \
0a132b2403030208010107c10a132b240303020801010bc10a132b2403030208 \
01010dc10a162b06010401da470f01c10b162b060104019755010501c2060108 \
00001100c206010c00001100c206011000001100c209122a8648ce3d030107c2 \
06122b81040022c206122b81040023c206122b8104000ac20a122b2403030208 \
010107c20a122b240303020801010bc20a122b240303020801010dc20a162b06 \
010401da470f01c20b162b060104019755010501c306010800001100c306010c \
61e4
raw apdu: 00c00000e4
response: sw=9000 datalen=228
dump: 00001100c306011000001100c309132a8648ce3d030107c306132b81040022c3 \
06132b81040023c306132b8104000ac30a132b2403030208010107c30a132b24 \
0303020801010bc30a132b240303020801010dc30a162b06010401da470f01c3 \
0b162b060104019755010501da06010800001100da06010c00001100da060110 \
00001100da09132a8648ce3d030107da06132b81040022da06132b81040023da \
06132b8104000ada0a132b2403030208010107da0a132b240303020801010bda \
0a132b240303020801010dda0a162b06010401da470f01da0b162b0601040197 \
550105019000Note that the command-responses are composed by two times.
Hand parsing the data object content:
fa 82 01 e2
c1 06
010800001100
c1 06
010c00001100
c1 06
011000001100
c1 09
132a8648ce3d030107
c1 06
132b81040022
c1 06
132b81040023
c1 06
132b8104000a
c1 0a
132b2403030208010107
c1 0a
132b240303020801010b
c1 0a
132b240303020801010d
c1 0a
162b06010401da470f01
c1 0b
162b060104019755010501
c2 06
010800001100
c2 06
010c00001100
c2 06
011000001100
c2 09
122a8648ce3d030107
c2 06
122b81040022
c2 06
122b81040023
c2 06
122b8104000a
c2 0a
122b2403030208010107
c2 0a
122b240303020801010b
c2 0a
122b240303020801010d
c2 0a
162b06010401da470f01
c2 0b
162b060104019755010501
c3 06
010800001100
c3 06
010c00001100
c3 06
011000001100
c3 09
132a8648ce3d030107
c3 06
132b81040022
c3 06
132b81040023
c3 06
132b8104000a
c3 0a
132b2403030208010107
c3 0a
132b240303020801010b
c3 0a
132b240303020801010d
c3 0a
162b06010401da470f01
c3 0b
162b060104019755010501
da 06
010800001100
da 06
010c00001100
da 06
011000001100
da 09
132a8648ce3d030107
da 06
132b81040022
da 06
132b81040023
da 06
132b8104000a
da 0a
132b2403030208010107
da 0a
132b240303020801010b
da 0a
132b240303020801010d
da 0a
162b06010401da470f01
da 0b
162b060104019755010501Here is a dump of my token (Yubikey 5.2.6). I used the new apdu command of gpg-card along with "undump | dumpasn1 -", which saves quite some time:
0 482: [PRIVATE 26] {
4 6: [PRIVATE 1] 01 08 00 00 11 00
12 6: [PRIVATE 1] 01 0C 00 00 11 00
20 6: [PRIVATE 1] 01 10 00 00 11 00
28 9: [PRIVATE 1] 13 2A 86 48 CE 3D 03 01 07
39 6: [PRIVATE 1] 13 2B 81 04 00 22
47 6: [PRIVATE 1] 13 2B 81 04 00 23
55 6: [PRIVATE 1] 13 2B 81 04 00 0A
63 10: [PRIVATE 1] 13 2B 24 03 03 02 08 01 01 07
75 10: [PRIVATE 1] 13 2B 24 03 03 02 08 01 01 0B
87 10: [PRIVATE 1] 13 2B 24 03 03 02 08 01 01 0D
99 10: [PRIVATE 1] 16 2B 06 01 04 01 DA 47 0F 01
111 11: [PRIVATE 1] 16 2B 06 01 04 01 97 55 01 05 01
124 6: [PRIVATE 2] 01 08 00 00 11 00
132 6: [PRIVATE 2] 01 0C 00 00 11 00
140 6: [PRIVATE 2] 01 10 00 00 11 00
148 9: [PRIVATE 2] 12 2A 86 48 CE 3D 03 01 07
159 6: [PRIVATE 2] 12 2B 81 04 00 22
167 6: [PRIVATE 2] 12 2B 81 04 00 23
175 6: [PRIVATE 2] 12 2B 81 04 00 0A
183 10: [PRIVATE 2] 12 2B 24 03 03 02 08 01 01 07
195 10: [PRIVATE 2] 12 2B 24 03 03 02 08 01 01 0B
207 10: [PRIVATE 2] 12 2B 24 03 03 02 08 01 01 0D
219 10: [PRIVATE 2] 16 2B 06 01 04 01 DA 47 0F 01
231 11: [PRIVATE 2] 16 2B 06 01 04 01 97 55 01 05 01
244 6: [PRIVATE 3] 01 08 00 00 11 00
252 6: [PRIVATE 3] 01 0C 00 00 11 00
260 6: [PRIVATE 3] 01 10 00 00 11 00
268 9: [PRIVATE 3] 13 2A 86 48 CE 3D 03 01 07
279 6: [PRIVATE 3] 13 2B 81 04 00 22
287 6: [PRIVATE 3] 13 2B 81 04 00 23
295 6: [PRIVATE 3] 13 2B 81 04 00 0A
303 10: [PRIVATE 3] 13 2B 24 03 03 02 08 01 01 07
315 10: [PRIVATE 3] 13 2B 24 03 03 02 08 01 01 0B
327 10: [PRIVATE 3] 13 2B 24 03 03 02 08 01 01 0D
339 10: [PRIVATE 3] 16 2B 06 01 04 01 DA 47 0F 01
351 11: [PRIVATE 3] 16 2B 06 01 04 01 97 55 01 05 01
364 6: [PRIVATE 26] 01 08 00 00 11 00
372 6: [PRIVATE 26] 01 0C 00 00 11 00
380 6: [PRIVATE 26] 01 10 00 00 11 00
388 9: [PRIVATE 26] 13 2A 86 48 CE 3D 03 01 07
399 6: [PRIVATE 26] 13 2B 81 04 00 22
407 6: [PRIVATE 26] 13 2B 81 04 00 23
415 6: [PRIVATE 26] 13 2B 81 04 00 0A
423 10: [PRIVATE 26] 13 2B 24 03 03 02 08 01 01 07
435 10: [PRIVATE 26] 13 2B 24 03 03 02 08 01 01 0B
447 10: [PRIVATE 26] 13 2B 24 03 03 02 08 01 01 0D
459 10: [PRIVATE 26] 16 2B 06 01 04 01 DA 47 0F 01
471 11: [PRIVATE 26] 16 2B 06 01 04 01 97 55 01 05 01
Error: Inconsistent object length, 2 bytes difference.
: }(let's ignore the error messages)
Why do you think that we need to care about the attestation key? Where possible I take in new code in account that we will have more OpenPGP keys, but right now I don't think that is makes sense to replace our data structures for that the 3 element arrays we currently use are okay for the 3 standard keys. We can latter see how to replace them. At one place I already introduced something new:
> scd getattr KEY-STATUS S KEY-STATUS OPENPGP.1 1 S KEY-STATUS OPENPGP.2 1 S KEY-STATUS OPENPGP.3 0 S KEY-STATUS OPENPGP.129 2 OK
Thus the key with id 0x81 should be represented in decimal. I am not sure why in the FA DO Yubikey uses 0x26; that would be OPENPGP.38 with the above scheme.
Perhaps, no change would be required.
My major concern is that: the data object for fingerprints C5 and C6 were defined as fixed-size 60-byte objects (and actually _is_ defined still in the current specification of 3.4), but it's 80-byte (newer Yubikey), which might cause problem(s).
Ok. However, I don't think that the fingerprint is really important. We can compute it anyway as long as we have the creation date. The keygrip is meanwhile more important but that is also easy to compute.
I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).