Thanks Andreas! I will experiment a little bit but I am looking forward to what Douglas has to say as he deployed this at ANL and if he is using it operationally, I would think we would need to understand the differences between the PIV card he uses and mine so it can be supported appropriately in the release.
-----Original Message----- From: Andreas Jellinghaus [mailto:a...@dungeon.inka.de] Sent: Wednesday, June 24, 2009 6:33 AM To: Boarman, Christopher L; Douglas E. Engert Cc: opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] Ticket #189 - Problems with opensc-pkcs11.so Hi Christopher, your first email in this thread was: >[opensc-pkcs11] card-piv.c:764:piv_handle_certificate_data: returning > with: 2308 > [opensc-pkcs11] card-piv.c:924:piv_read_binary: returning with: 2308 > [opensc-pkcs11] pkcs15-cert.c:115:sc_pkcs15_read_certificate: called > > From there, I traced the call into asn1.c, in the function > sc_asn1_read_tag, and the following is the code segment where the final > point of failure occurs: using the log file you provided, I check the data downloaded by the piv code, and everything looks fine: 1509 bytes of data, containing a compound tag with inside a 0x70 and 0x71 tag. 0x70 has the compressed certificate, 0x71 has the single byte "01" as marker for "compressed" I guess, and there is a final tag 0xfe with length 00 and no value - not evaluated by the opensc code, I guess some end-of-content marker. the log file shows the code is properly decompressed to 2308 bytes. ok, I wrote a program to decode those bytes and have a look at the decoded data... the data is a fine certificate in DER format. the size is 2658 bytes. so the problem is opensc thinks the file should be only2308 bytes, requests only 2308 bytes, and thus gets a broken cert that returns an error when looking into it. The problem is here: [opensc-pkcs11] pkcs15-piv.c:298:sc_pkcs15emu_piv_init: PIV-II adding certs... [opensc-pkcs11] pkcs15.c:1672:sc_pkcs15_read_file: called, path=0101cece, index= 0, count=-1 [opensc-pkcs11] card.c:285:sc_lock: called [opensc-pkcs11] card.c:532:sc_select_file: called; type=2, path=0101cece [opensc-pkcs11] card-piv.c:1608:piv_select_file: called [opensc-pkcs11] card-piv.c:1579:piv_find_obj_by_containerid: called [opensc-pkcs11] card-piv.c:1580:piv_find_obj_by_containerid: str=0x0101 [opensc-pkcs11] card-piv.c:1585:piv_find_obj_by_containerid: returning with: 3 [opensc-pkcs11] card-piv.c:1665:piv_select_file: returning with: 0 [opensc-pkcs11] card.c:554:sc_select_file: returning with: 0 [opensc-pkcs11] card.c:399:sc_read_binary: called; 2308 bytes at index 0 sc_pkcs15_read_file calls sc_read_binary with a buffer that is too small. where did it get the size? frm sc_select_file. but we have no debug information what that function did and how it got that value. ah, piv_find_obj_by_containerid seems to be the problem. it looks at the static struct piv_object piv_objects[] = { data in card-piv.c and that has a line: { PIV_OBJ_X509_PIV_AUTH, "X.509 Certificate for PIV Authentication", "2.16.840.1.101.3.7.2.1.1", 3, "\x5F\xC1\x05", "\x01\x01", 1895+9+4+400} , 1895+9+4+400 = 2308 replace that with a higher value and you should be fine. I have no clue why we have that small value, and what the best way to fix this problem is. lets wait till Douglas can have a look. but from my side, that "default size" ends up as the size of the buffer sc_read_file allocates, and thus only that many bytes are passed back from the lower level functions, and thus an incomplete certificate is returned to the higher layer, which is refused as invalid, so that is the reason the whole thing does not work. also the constants you mentioned comparing pkcs11-tool, they are all hard coded in card-piv.c or pkcs15-piv.c. so it is normal, that different software returns different names. If PIV standard dictates the names, we should fix our software. if not, then it is a PIV problem. with PKCS#15 the displayed string for a certificate is in the directory files, thus the software doesn't need such hard coded values. if you want to experiment, you could add increase the hard coded sizes and see if it helps. douglas, can you look at the decompression code and add some debugging, so we see the size after decompression vs. the number of bytes returned? Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
