Hi Christopher, I had a quick look at the code. in ASN.1 TLV I guess the len is incoded like this: a) the value to be eincoded is 127 or smaller. in that case length is that value. b) the value is higher than that. in that case it can be any value from 128 up to 4 bytes long. the first byte has the highest bit set, and encodes how many bytes are stored as length. for example 0x82 would be 0x80 = marker for a value > 128, and 2 = stored in the next two bytes. the following 1..4 bytes contain the length in MSB-first byte order.
could you show us a hexdump for that code? I guess the value that is not properly parsed was read prior by some code, so with a high debug value, I hope you have a hexdump of the buffer in question in the log file. maybe some software forgets to encode a value 128..255 with proper 0x81 <length-byte> notation and placed it as <length-byte> instead? or maybe in piv such a notation is not necessary, but the code didn't take care of this? unfortunatly Douglas (author of the piv code and expert on this) might be on vacation right now, so an answer could take a week. > I am going to continue to work on it a little bit but I could use some help. if you can try opensc again, and create a debug log including hex dumps, maybe we can a) find the content that is not properly asn1-decoded and b) the function that tries to decode it, and thus descide if it is a problem with the data on card or with some opensc/piv code. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
