Closed
Bug 288184
Opened 20 years ago
Closed 20 years ago
Name Constraints DNS name comparison may have fault.
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 231223
3.9.1
People
(Reporter: hanfei.yu, Assigned: wtc)
Details
In lib/certdb/genname.c, calling compareDNSN2c with name = "mycertificates.gov" and constraints = "certificates.gov", the compareDNSN2C returns success. From the comment of compareDNSN2C, this is the correct behavior (** foo.bar.com nofoo.bar.com MATCHES), but this behavior causes NIST test 4.13.38 fail. I wonder if it really should behave as this :-) =>[1] compareDNSN2C(name = 0x5e954, constraint = 0x5e99c), line 1162 in "genname.c" [2] cert_CompareNameWithConstraints(name = 0x5e950, constraints = 0x5e998, excluded = 0), line 1311 in "genname.c"
| Assignee | ||
Comment 1•20 years ago
|
||
According to bug 231223, NSS 3.9.1 or later should pass NIST test 4.13.38. I don't know why you see a test failure. In any case, this is a duplicate bug. *** This bug has been marked as a duplicate of 231223 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
| Assignee | ||
Comment 2•20 years ago
|
||
Using the line numbers in the stack trace, I concluded that you must be using NSS 3.9. This explains why you see a test failure because this bug was fixed in NSS 3.9.1. Please use the latest NSS release, NSS_3_9_5_RTM. You may want to use NSS_3_10_BETA2 because we are very close to release NSS 3.10.
Target Milestone: --- → 3.9.1
Version: 3.0 → 3.9
You need to log in
before you can comment on or make changes to this bug.
Description
•