We currently have an issue with the fact that the PKCS#11 blob with certs and keys, that gets written to a token, locates its various cert and key object with indexed values like the following:

C0 - cert 0
k1 - priv key of C0
k2 - pub key of C0

...

C2 - cert 2
k4 - prive key of C2
k5 - priv key of C2

Note that the formula is k(x) = C 2 and C2 + 1

Right now in coolkey, at least in Fedora, each object to be located by libcoolkey has to have an index between 0 and 9, due to the fact that the index is encoded as ascii as part of the muslce object id format.

If the index goes to 10 or more, problems occur for obvious reasons. The problem is thus two fold.

1. We need to make sure the libcoolkey that actually uses certs can support more than 0-9 for object id's. There is a question of whether or not some version of the rhel5 version of coolkey was fixed to do this. This will require some tracking down. As of now it looks like the current Fedora coolkey and possibly rhel7 has this 0-9 limitation, stay tuned.

2. There is a bunch of code in TPS that creates and parses these objects that will eventually be blasted down to the token during an enrollment operation. We need to make sure that whatever the limitation for an index is, either 9 or whatever we must enforce that in the code and not allow someone to try to save off say C10, which is not allowed.

This part will be the major portion of the work for this ticket in TPS. Also if the limit is raised beyond 9, we need to make sure that the current code can handle THAT and if not fix it to allow such.