Closed
Bug 982340
Opened 10 years ago
Closed 8 years ago
CertVerifier/NSSCertDBTrustDomain incorrectly uses the NSS trustbit in the case of SSLClient
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: cviecco, Assigned: cviecco)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
9.18 KB,
patch
|
keeler
:
feedback-
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Updated•10 years ago
|
Blocks: mozilla::pkix
Comment 1•10 years ago
|
||
Please include some context so that people following the tracking bug know what's going on. Thanks, Monica
Updated•10 years ago
|
Summary: Insanity::pkix incorrectly uses the NSS trustbit in the case of SSLClient → mozilla::pkix incorrectly uses the NSS trustbit in the case of SSLClient
Updated•10 years ago
|
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → cviecco
Assignee | ||
Comment 2•10 years ago
|
||
So this solves MOST of the issues, I still got to figure out why and explicit distrust over an intermediate does not work. Potentially problematic issues: 1/ what do you think of having the two constructors 2. the new input paramter is not an enum but an unsigned int.
Attachment #8409061 -
Flags: feedback?(dkeeler)
Assignee | ||
Updated•10 years ago
|
Attachment #8409061 -
Flags: feedback?(brian)
Comment on attachment 8409061 [details] [diff] [review] fix-ssl-client-trust-mozpkix Review of attachment 8409061 [details] [diff] [review]: ----------------------------------------------------------------- I'm not sure we should spend a lot of effort supporting certificateUsageSSLClient, particularly when it requires a different trust bit on the root. I think we should just document that the way NSSCertDBTrustDomain interprets NSS's certdb trust bits is that if a cert has the CERTDB_TRUSTED_CA, it can be a trust anchor for any usage. If not, then it isn't a trust anchor for anything. ::: security/manager/ssl/tests/unit/test_cert_trust.js @@ -128,5 @@ > // Now tests on the SSL trust bit > setCertTrust(cert_to_modify_trust, 'p,C,C'); > check_cert_err_generic(ee_cert, SEC_ERROR_UNTRUSTED_ISSUER, > certificateUsageSSLServer); > - check_cert_err_generic(ee_cert, useMozillaPKIX ? 0 //XXX Bug 982340 I'm not actually sure this is a bug - when we verify for certificateUsageSSLClient, CertVerifier uses the trustEmail bit, which is set in this case. @@ -157,5 @@ > check_cert_err_generic(ee_cert, isRootCA ? useMozillaPKIX ? SEC_ERROR_UNKNOWN_ISSUER > : SEC_ERROR_UNTRUSTED_ISSUER > : 0, > certificateUsageSSLServer); > - check_cert_err_generic(ee_cert, isRootCA ? useMozillaPKIX ? 0 // XXX Bug 982340 Same here.
Attachment #8409061 -
Flags: feedback?(dkeeler) → feedback-
Assignee | ||
Updated•10 years ago
|
Blocks: mozilla::pkix-beta
Assignee | ||
Updated•10 years ago
|
No longer blocks: mozilla::pkix
Comment 4•10 years ago
|
||
Comment on attachment 8409061 [details] [diff] [review] fix-ssl-client-trust-mozpkix I think one reviewer is good enough, and I'm happy for that to be David. Please document (whereever the trust flags are defined in NSS) which flags correspond to which things. For example, is CERTDB_TRUSTED_CLIENT_CA supposed to be used for id-kp-emailProtection too? Note that any place Firefox is verifying a certificate for id-kp-clientAuth is almost definitely a bug. The server (hopefully) has a totally different set of trust anchors and usually there's no reason for Firefox to trust any of those trust nachors. Thus, it doesn't make sense for Firefox to try to verify an SSL client cert chain.
Attachment #8409061 -
Flags: feedback?(brian)
Updated•10 years ago
|
Blocks: mozilla::pkix-nss
Updated•10 years ago
|
No longer blocks: mozilla::pkix-beta
Updated•10 years ago
|
Summary: mozilla::pkix incorrectly uses the NSS trustbit in the case of SSLClient → CertVerifier/NSSCertDBTrustDomain incorrectly uses the NSS trustbit in the case of SSLClient
This doesn't seem to be a problem in practice.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•