Bug 720050 - token label limit of 32 chars not quiiite enough
Summary: token label limit of 32 chars not quiiite enough
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coolkey
Version: 5.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Bob Relyea
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-08 20:45 UTC by jared jennings
Modified: 2015-01-04 23:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-11 17:45:36 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description jared jennings 2011-07-08 20:45:42 UTC
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.

Comment 1 Bob Relyea 2011-07-08 21:06:44 UTC
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

Comment 2 jared jennings 2011-07-11 13:17:22 UTC
OK, thanks for your attention and info, Bob. If I haven't just managed to close this bug please close it yourself.


Note You need to log in before you can comment on or make changes to this bug.