Hide Forgot
Description of problem: We have a known patch that allows coolkey to process object id's for certs and keys that are greater than the integer value of 9. The standard muscle object id consists of two ascii characters once decoded. 1. One latter c for cert and k for key. 2. One ascii char representing the id Previously we could only support ascii 0 to ascii 9. The fix allows us to encode the ascii letters a - z, which represent keys 10 - 36 .
Jack, can you show me how the TPS code currently assigns the values? The id numbers are generated by TPS, not by coolkey, but coolkey needs to interpret them. bob
Bob: I recently found an issue in TPS where it it was only using the one char for the id even if it the cert was say C10, it would use 1. I've already taken the patch from el5 for coolkey and made my own build. I then fixed TPS in my tree to observe the id as per the existing patch. Thus 0-9 would be 0-9, A to Z would be the next block and a to z would be the next block. All seems to be working. So simply getting the patch from el5 in el7 should fix us up.
Ah, I thought I had fixed this issue once. Obviously the patch didn't get propogated everywhere. I believe we'll need it in RHEL 6 as well.
Jack, there's a bug in this patch, which has now made its way into Fedora 22 through Rawhide in addition to RHEL 5 (as "coolkey-more-keys.patch" in the source RPM). Please fix this in all these distributions. (Also consider adding this patch to RHEL 6 and RHEL 7.) > diff -up ./src/coolkey/slot.h.more_keys ./src/coolkey/slot.h > --- ./src/coolkey/slot.h.more_keys 2014-04-22 10:13:20.127953302 -0700 > +++ ./src/coolkey/slot.h 2014-04-22 10:18:32.426953182 -0700 > @@ -487,7 +487,17 @@ class Slot { > return (char) (objectID >> 24) & 0xff; > } > unsigned short getObjectIndex(unsigned long objectID) const { > - return (char )((objectID >> 16) & 0xff) - '0'; > + char char_index = (char) ((objectID >> 16) & 0xff); > + if (char_index >= '0' && char_index <= '9') { > + return char_index - '0'; > + } > + if (char_index >= 'A' && char_index <= 'Z') { > + return char_index - 'A' + 10; > + } > + if (char_index >= 'a' && char_index <= 'z') { > + return char_index - 'a' + 26; This should add 36 instead of 26 (because 'A'-'Z' maps to 10-35). > + } > + return 0x0100 + char_index; > } > > // actually get the size of a key in bits from the card
Thanks, we will take a look at this and act accordingly. This bug btw, is to put this in rhel 7.
fixed in coolkey-1.1.0-34.el7
(In reply to Bob Relyea from comment #8) > fixed in coolkey-1.1.0-34.el7 Does this contain the fix I described in comment #6? That fix hasn't been pushed to any Fedora branch or to RHEL 5. Jack, did you take a look?
[root@dhcp129-54 sctests]# rpm -qi coolkey Name : coolkey Version : 1.1.0 Release : 35.el7 Architecture: x86_64 Install Date: Thu 04 Aug 2016 11:38:21 AM EDT Group : System Environment/Libraries Size : 300220 License : LGPLv2 Signature : RSA/SHA256, Thu 28 Jul 2016 01:24:44 PM EDT, Key ID 938a80caf21541eb Source RPM : coolkey-1.1.0-35.el7.src.rpm Build Date : Fri 01 Jul 2016 05:09:30 PM EDT Build Host : x86-034.build.eng.bos.redhat.com Relocations : (not relocatable) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://directory.fedora.redhat.com/wiki/CoolKey Summary : CoolKey PKCS #11 module Verified by recovering 13 certs/keys on a Gemalto 64K smartcard using externalReg tokentype. Set appletMemorySize to 10000.
Roshni: Dave: Bob: Did this make it in to el7? Roshni, even if not, this fix does work for the most common large number, slightly greater than 10. I think Dave's fix was discovered in the upper reaches of the range which we are not likely to see. Thus, even if not, I think we MAY consider closing this one and creating a new bug specific to Dave's concern. That is if Bob did not put this fix into el7. Discussion welcome of course.
Jack, Do I have to test this using the other supported cards SC650 (SCP01 and SCP02) ?
There is nothing card specific about this fix, but you might want to try one run for sanity.
Successfully tested using SC650 (SCP01 and SCP02) cards
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2465.html