I am back from vacation.
From what I can tell from your emails, the certificate is larger then what
NIST 800-73-1 Appendix A says the max size of the certificate object, 1856.
But 800-73-2 Part 1 in Table A-5 says the max size is 1856 with a footnote:
"Recommended length. Certificate size can exceed indicated length value."
The OpenSC code was using these max values for the buffer passed to read binary
and the max size to read.
{ 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} ,
But it now looks like there is no limit on how big an object can be, so the
logic
needs to change to determine the size for the buffer from the object, as it is
being read, and reallocate the buffer, or do a partial read of the object to get
its length, or use a 65K buffer.
For now, your trick of adding a 1000 to the size should work. Or change the
1895+9+4+400
for each of the certificates to 65535.
I will look at doing the reallocation of the buffer based on the size as
indicated in the
asn1 size as read from the object, which should then work for any object.
Our PIV certs are issued by OMB, who is issuing yours? Why are they so much
larger?
are they gziped?
Boarman, Christopher L wrote:
> 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
>
>
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
