Rainbow accelerator certificates are not visible

RESOLVED FIXED in 3.4.1

Status

NSS
Libraries
P1
blocker
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Rob Crittenden, Assigned: Robert Relyea)

Tracking

3.4.1
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
Regression from NSS 3.3.1.

Using a Rainbow accelerator, installed certificates are not visible.

The module was added with:

modutil -add "ISG 2.0 Cryptoki Interface" -nocertdb -libfile
/usr/lib/libcryptoki22.so -dbdir . -mechanisms "RSA:DSA:DH"

A certificate was requested and installed using the NES 6.0 admin UI. In NES 6.0
the certificate is visible under Manage Certificates and using certutil.

The certificate is not visible to the NES 6.1 admin UI nor NSS 3.4 certutil.
(Reporter)

Updated

15 years ago
Priority: -- → P1
(Assignee)

Comment 1

15 years ago
Rob, can you tell me which machine I can go to with the rainbow card installed?

thanks,

bob

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

15 years ago
OK, like nCipher, Rainbow is completely chocking on any attribute request that
has an unknown attribute.

Unlike nCipher, Rainbow is half implementing the spec. It's setting the length
field to -1 in this case: only it's setting it for *all* the attributes, not
just the one it doesn't like.

The resulting patch fixed the problem. It has an undesirable side effect of
causing multiple fetches of unknown attributes from perfectly compliant tokens,
however. This side effect should be functionally inocuous.

bob
(Assignee)

Comment 3

15 years ago
Created attachment 78369 [details] [diff] [review]
Handle yet another non-complient PKCS #11 token semantic
(Assignee)

Comment 4

15 years ago
Tip builds for testing are available at
/h/jordan/space2/nsstip/mozilla/dist/SunOS5.x_DBG.OBJ
where x is either 6 or 8 (both have the fix in them).

nss3.4 branch builds are
/h/jordan/sapce2/nsstip/mozills/dist/AIX4.3_DBG.OBJ

Comment 5

15 years ago
Comment on attachment 78369 [details] [diff] [review]
Handle yet another non-complient PKCS #11 token semantic

"Each standards-compliant token is compliant in the same way, each
non-compliant token is not compliant in its own way."

This looks like a low-risk solution.  Looks good to me.
Attachment #78369 - Flags: review+
(Reporter)

Comment 6

15 years ago
Rainbow is looking at this problem in their driver. From my reading we have
simply relaxed the rules regarding the length check? So if they fix in their
driver the NSS patch won't have a negative impact, right?

Comment 7

15 years ago
Rob asked:
> So if they fix in their driver the NSS patch won't have a
> negative impact, right?

That's right.

This fix has been checked into the tip and the NSS_3_4_BRANCH
and will be in NSS 3.4.1.  Marked the bug fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.4.1
You need to log in before you can comment on or make changes to this bug.