| Summary: | token label limit of 32 chars not quiiite enough | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | jared jennings <jjennings> |
| Component: | coolkey | Assignee: | Bob Relyea <rrelyea> |
| Status: | CLOSED NOTABUG | QA Contact: | Chandrasekar Kannan <ckannan> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.8 | CC: | benl |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-11 17:45:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
That's right. This is a PKCS #11 spec limit. All PKCS #11 tokens have this limit. The certificates labels have no limit. There's not anything we can do about that since it's a limit in the standard. bob OK, thanks for your attention and info, Bob. If I haven't just managed to close this bug please close it yourself. |
Description of problem: I have a user who has a CAC which has certificates issued to a common name like WEFOHWFEOIWEF.WEOFIH.Z.1234567890. If you count carefully you will see that that common name has 33 characters. When he is prompted for his PIN, the name shown is missing characters, e.g. WEFOHWFEOIWEF.WEOFIH.Z.123456789. Version-Release number of selected component (if applicable): coolkey-1.1.0-15.el5 nss-3.12.8-4.el5_6 nss-tools-3.12.8-4.el5_6 How reproducible: 1. Obtain a CAC with certificates having a common name longer than 32 characters. Let's say it's WEFOHWFEOIWEF.WEOFIH.Z.1234567890. 2. Create a new NSS database: mkdir /tmp/nss; modutil -create -dbdir /tmp/nss 3. Add CoolKey to the database: modutil -add coolkey -libfile /usr/lib64/pkcs11/libcoolkeypk11.so. 4. List the tokens: modutil -list -dbdir /tmp/nss. 5. In the output, you'll see something like this: slot: Broadcom 5880 (0123456789ABCD) 00 00 token: WEFOHWFEOIWEF.WEOFIH.Z.123456789 (Note truncated name as compared to certificate common name.) 6. List certificates: signtool -L -d /tmp/nss. See at the end, WEFOHWFEOIWEF.WEOFIH.Z.123456789:CAC ID Certificate WEFOHWFEOIWEF.WEOFIH.Z.123456789:CAC Email Signature Certificate WEFOHWFEOIWEF.WEOFIH.Z.123456789:CAC Email Encryption Certificate 7. Obtain one of the certificates and verify that the cert itself does not have a truncated common name: certutil -L -d /tmp/nss -n 'WEFOHWFEOIWEF.WEOFIH.Z.123456789:CAC ID Certificate' and look for "Subject:" in the output. Verify that it ends with 1234567890 not 123456789. It may be possible to replicate this problem with a CoolKey, not strictly a CAC. I think that the name shown may be passed out of CoolKey to NSS via the label or manufacturerID fields in the CK_TOKEN_INFO structure, because those fields are 32 CK_UTF8CHARs long and need space for a null ('\0') at the end. I tried increasing the size of these in CoolKey, but I suppose the size NSS was expecting did not change, because the modutil -list aborted with this message: *** stack smashing detected ***: modutil terminated Aborted and because the 32-character limits also show up in /usr/include/nss3/pkcs11t.h. The applications I'm really concerned with are pam_pkcs11 and Firefox, but I believe they both do their work via NSS, and deemed that it would be simpler to demonstrate the problem using nss-tools.