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 0020
And 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 \ 550105019000
Note 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 162b060104019755010501
Here 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).