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
