133643 - Unable to import P12 file

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[Neil Brittliff]

Unable to import PKCS12 files that could by imported with 3.3.1 version into a 
NSS database.

Message: PKCS12 decode import bags failed: Unable to import
Code:    -8099

I will send you the P12 file

Comment 1

[Neil Brittliff]

Attachment: P12 File - Password: Pass-123

The Password for the P12 is:

Pass-123

Comment 2

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 3

[Patrick]

perhaps related to 128586
?

Comment 4

[Neil Brittliff]

The P12 file was generated via Baltimore's UNICERT product.  I have done some 
more investigation it appears that NSS decodes the P12 correctly but has some 
problem in adding the Private Key.  We have found that some P12 files generated 
from UNICERT do seem to work, and some fail due to this problem.  I can attach 
a P12 file that does work and imports successfully.  This is a serious problem 
for us - I hope you can fix this or at least point us in the right direction.

These P12 file could be imported with NSS 3.1.1

Comment 5

[Marc Jadoul]

I have the same problem. We are using Baltimore and Certificates generated from
WebRAO or RAO as P12 files can't in general be imported in Mozilla while it work
well with Communicator/MIE/openssl.
But it is not limited to Baltimore: I can't import certificate exported from
W2K/MIE6 either.
If you need it, I can provide tests p12.

Marc

Comment 6

[Wan-Teh Chang]

If you know how to build NSS yourself, could you apply
Bob Relyea's patch in bug 128586 (attachment 78489 [details] [diff] [review]) and
see if it fixes this problem?

Mr. Marc Jadoul, yes, if you could provide test p12
files, that would be helpful.

Comment 7

[Marc Jadoul]

Attachment: Demo P12

Password for the P12 files are	 1234abC!    . These are all demo certs without
any values.
There are several type of P12: some issued with Unicert RAO 3.5.3 wich is a a C
application. Some other where issued from the WebRAO 2.3, a java plugin.
Some are exported from MIE6.
Certificates are issued from different CA too. I included 2 P7C containing the
chains. One of the cert is from GlobalSign for which the root is already in
Mozilla. Of course the chains should also be in p12.
Then, certificates are with different Key Usage: N or Normalised for encryption
and Q or Qualified for Signing.
I hope it help. If you need P12 with certs having specific content (KU,
emails...) it is also possible.

Marc

Comment 8

[Neil Brittliff]

In Response to Comment #6 - applied patch to version 3.4.1 RC1, but it did not 
fix the problem

Comment 9

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 10

[Robert Relyea]

Attachment: Fix bugs in RSA_KeyCheck()

So the basic problem:

NSS 3.4 introduced a security feature in which it checks the validity of the
RSA private key components whenever such a key is generated or imported into
the software token.

This check required  p > q, and if it wasn't, we would swap the p and q values.
this automatically makes the coefficient wrong since its the inverse of q mod
p. We are still investigating the requirement of p > q, but it doesn't affect
the import because certain calculated values can be re-calculated as long as p,
q, m, d, and e (prime1, prime2, modulus, private exponent, and public exponent)
are correct. Unfortunately the code was failing when trying to recalculate
these values. This patch fixes those failures, and now these pkcs12 files can
be imported into the softoken.

(Ironically, these keys would have succeeded if the were imported into a
different token, because the RSA_PrivateKeyCheck() would have been bypassed).

Comment 11

[Robert Relyea]

This patch is check into the NSS tip.

Comment 12

[Wan-Teh Chang]

Set target milestone to 3.4.2.

Bob, please also check in this fix on the NSS_3_4_BRANCH.
Thanks!

Comment 13

[Wan-Teh Chang]

Bob, please also check in the patch in bug 128586 (attachment 78489 [details] [diff] [review])
on the NSS_3_4_BRANCH.  Thanks.

Comment 14

[Wan-Teh Chang]

Comment on attachment 82063 [details] [diff] [review]
Fix bugs in RSA_KeyCheck()

Ian, could you review this patch?  Thanks.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

I believe thie patch above is correct, so r=nelsonb.

But I would also propose that we change the key check code with 
respect to when it swaps p with q.  
I'd propose that, if p < q but all the tests pass, then we should not
swap p and q.
I'd propose that we only swap p with q (and d_p with d_q) when the
p < q; all the tests on n, p, q, d and e pass; but one or more of the
values d_p, d_q, or qInv is found to be wrong.  In that case, I'd 
propose that we swap p with q, and d_p with d_q, and then recompute
any of d_p, d_q and qInv as needed.

But this proposal is merely an efficiency enhancement, not P1.

Comment 16

[Neil Brittliff]

I have tested the Patch and it works fine !

Comment 17

[Wan-Teh Chang]

Thanks for verifying the bug fix, Mr. Brittliff.

Marked the bug fixed.

Comment 18

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch. Pls check this in
asap. thanks!

Comment 19

[lchiang]

[e-mail] - can you verify this bug fix in 1.01 branch? 
When verified, pls replace fixed1.0.1 keyword with verified1.0.1.  Thanks.

Comment 20

[Charles Rosendahl]

Verified - Been fixed for a while.