Tue, Jul 28
Mon, Jul 27
Well, it is now defined. We use a CMS object containing an OpenPGP keyblock container. Right, there is no open standard for it but with OIDs you don't really need them. it is a bit of a hack but it works with the majority of deployed cards and the overhead is quite small.
@wener But it uses undefined data structure of "certificate" DO, IIUC. My point is defining DOs for OpenPGP, so that host side can construct OpenPGP object from those DOs.
Sun, Jul 26
Item 2 and 3 have already been solved by allowing to store a minimal key.
Tue, Jul 21
Fri, Jul 17
That could also be the reason for some strange behaviour I have sometimes with my bunch or readers. I have not had the time to look into this and thus opted for a gpgconf --kill scdaemon which fixes things quickly but of course this is a bad workaround.
I am happy that your use case will be supported, and the bug was fixed before the release.
It's me who say "thank you" to you!
46d185f60 doesn't segfault and does prints the YubiKey card information, even without reader-port configured. Perfect! That will fix the issue for me. Looking forward to seeing it released. Thanks again @gniibe!
Thanks a lot.
I pushed a fix as rG46d185f60397: scd: PC/SC: Don't release the context when it's in use..
Ah, I identified an issue.
While it's in a loop of trying readers (in select_application in scd/app.c), it should not deallocate resources to access readers, even if reference count == 0.
Thanks for your testing.
Thanks for the detailed explanation, I'm glad to hear it! Out of curiosity, I tried running echo 'serialno openpgp' | ./scd/scdaemon --log-file - -v --server built from 43000b043 and it printed:
Thanks for your report.
Major reason was multiple card readers/tokens were not supported by PC/SC handling of scdaemon, only a single reader was assumed, so, user had to specify one.
Multiple reader by PC/SC support was added in master (to be 2.3), so, I think the problem is solved in master.
Jun 2 2020
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).
May 29 2020
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.
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).
May 28 2020
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:
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:
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
And here is (raw) dump of the data object FA:
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
May 7 2020
Apr 2 2020
It runs like:
$ gpg-connect-agent "scd devinfo --watch" /bye S DEVINFO_START S DEVINFO_END S DEVINFO_STATUS new S DEVINFO_START S DEVICE generic D276000124010200F517000000010000 openpgp S DEVINFO_END S DEVINFO_STATUS removal S DEVINFO_START S DEVINFO_END OK $
Push the change to master.
Mar 20 2020
The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.
Mar 19 2020
Mar 18 2020
Backported to 2.2