Last Comment Bug 136253 - Rainbow accelerator certificates are not visible
: Rainbow accelerator certificates are not visible
Status: RESOLVED FIXED
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.4
: Sun Solaris
: P1 blocker (vote)
: 3.4.1
Assigned To: Robert Relyea
: Sonja Mirtitsch
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-08 15:10 PDT by Rob Crittenden
Modified: 2002-04-11 15:36 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Handle yet another non-complient PKCS #11 token semantic (689 bytes, patch)
2002-04-09 11:02 PDT, Robert Relyea
bugz: review+
Details | Diff | Splinter Review

Description Rob Crittenden 2002-04-08 15:10:11 PDT
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.
Comment 1 Robert Relyea 2002-04-08 17:03:24 PDT
Rob, can you tell me which machine I can go to with the rainbow card installed?

thanks,

bob
Comment 2 Robert Relyea 2002-04-09 11:01:03 PDT
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
Comment 3 Robert Relyea 2002-04-09 11:02:58 PDT
Created attachment 78369 [details] [diff] [review]
Handle yet another non-complient PKCS #11 token semantic
Comment 4 Robert Relyea 2002-04-09 11:30:08 PDT
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 Ian McGreer 2002-04-09 11:32:26 PDT
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.
Comment 6 Rob Crittenden 2002-04-11 11:21:51 PDT
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 Wan-Teh Chang 2002-04-11 15:36:11 PDT
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.

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