Within the FASC-N, they are two strings of data that can be used in incremental fashion. The first is credential issuer number and the other is person unique number. The credential issuer number is 6 digits. TWIC uses this number to count the amount of cards issued by a TWIC facility/location. So the very first one would have a number of 000001. The problem occurs when this number increments to more than 099999 which some locations have now hit. The primary problem is that when this first two numbers of this string are 10 RCM interprets this incorrectly and truncates the rest of the data that comes after. The second problem area occurs in the person unique string when 10 appears in the sixth and seventh location in that 10 digit value.

noticed that the user has 00 in the bytes so RCM may be forcing a truncation on the NULL.

The RCM side is expecting an octetString, and we are feeding the bytes into the RCM function XudaXPTOctetsSet, maybe it dislikes 00.

The entire KCM API is a C API, Which Card Manager pass the C++ std::string value we've read in and its length, into the underlying API as a source for octetString. 

The issue is that the 18th byte is a NULL (00), and the string is truncated at the end of the 17th byte. This would seem to fit.

I ran a few queries on this to try and bound the scope of the problem, and found that the count of TWICs issued containing 00 in the FASC-N is 26,650. Spot checking the results the hypothesis seems to hold up.

Cert: 00 b1 f4 e3 08 1e b5 36 be 5e bf 9a cb 8c a9 33 6c

FASC-N D7 03 39 D8 41 C8 AC 14 20 59 25 A1 68 58 21 09 11 00 CC

82 87 03 39 A3 E4

subjectAltName>otherName>twicFASC-N: d7 03 39 d8 41 c8 ac 14 20

subjectAltName>otherName>59 25 a1 68 58 21 09 11

Cert: 45 41 61 91 d7 1c 88 19 70 af 42 d1 9a 6a da 8f

FASC-N: D7 03 39 D8 41 81 2D 00 CE 01 0D A1 68 58 21 0E 5B 5E 09 B0 87 03 39 A3 ED

subjectAltName>otherName>twicFASC-N: d7 03 39 d8 41 81 2d

RCM API error in calculating the length of string at the time of creating general names extension.