libpkix name constraints check treats CN as DNS name when it should not
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
People
(Reporter: ftweedal, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
7.93 KB,
patch
|
ueno
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Steps to reproduce:
-
Have a CA with DNS name constraints permitted subtree.
-
Verify a certificate with an Extended Key Usage not containing id-kp-serverAuth (e.g. an OCSP signing certificate), whose Subject DN CN attribute does not resemble a DNS name within the permitted subtree.
-
Verify the certificate (using libpkix):
NSS_ENABLE_PKIX_VERIFY=1 certutil -d $NSSDB -f $PWDFILE -V -e -n $NICKNAME -u O
Actual results:
Verification fails:
# NSS_ENABLE_PKIX_VERIFY=1 certutil -d $NSSDB -f $PWDFILE -V -e -n $NICKNAME -u O
certutil: certificate is invalid: The Certifying Authority for this certificate is not permitted to issue a certificate with this name.
Expected results:
Verification should succeed. The CN should not be treated as a DNS name unless the certificate being validated is a server authentication certificate (i.e. id-kp-serverAuth is asserted in the Extended Key Usage extension). For compatibility, it may be acceptable to continue treating CN as a DNS name if the certificate does not have the EKU extension.
I will follow up with a patch soon.
Reporter | ||
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
Maybe an RH NSS developer could review this?
Also, fixes should go together with a test.
Updated•6 years ago
|
Reporter | ||
Comment 3•6 years ago
|
||
Comment 4•6 years ago
|
||
Reporter | ||
Comment 5•6 years ago
|
||
Thanks Daiki, I'll add a test and provide an updated patch next week (or reach out if I cannot work out what to do). Have a great weekend!
Reporter | ||
Comment 6•6 years ago
|
||
Now with test.
Comment 7•6 years ago
|
||
Comment 8•6 years ago
|
||
Description
•