757854 - Add automatic testing for name constraint extensions

Status: NEW

(NSS :: Test, defect, P3)

Description

[Kai Engert (:KaiE:)]

The NSS test suite should test that name constraints in certificates are treated correctly.

Comment 1

[Kai Engert (:KaiE:)]

How could we add testing for name constraints to the NSS test suite?

Since we prefer self-contained testing, we'd need a way to resolve a couple of domains to the localhost IP address.

Could we add testing hooks to the NSPR DNS resolver?

Comment 2

[Wim Lewis]

The tests in tests/pkits/pkits.sh do test name constraints via the NIST path validation test dataset, if that dataset is available. Is there functionality that those tests don't cover?

Comment 3

[Martin Ukrop]

NIST PKITS name constraints tests (group 4.13) only cover directoryNames, rfc822Names (emails), DNSNames and URIs. That means no tests for IP constraints are present.

Furthermore, tests for emails and DNS names cover only simple cases (mostly onlt a single constraint) -- so testing intersections of multiple constraints subtrees would be nice.

Comment 4

[Martin Ukrop]

Attachment: Patch with new DNS constraints tests

Attaching a patch with extension of DNS tests (ported from GnuTLS).
There are IP tests to port as well, but I ran into other problems regarding the IP constraints and certutil (but hopefully they will be added soon).

Comment 5

[Martin Ukrop]

IP name constraints depend on bug 1305750 to be implemented to allow for self-contained tests using certutil to generate test certificate.

Will add a second path with email tests to this bug soon.

Comment 6

[Martin Ukrop]

Attachment: New DNS and email constraints tests

New version of the constraints tests patch. In addition to DNS constraints tests, it also has email constraints tests.
The basic cases that are covered by NIST PKITS are mostly left out (since PKITS is a part of the NSS test suite). It tests more detailed behaviour concerning DNS and emails.

Comment 7

[Kai Engert (:KaiE:)]

(a)
For verification, you use certutil -V with "-u C". That parameter means:
 "verify if this certificate is valid to be used as an SSL/TLS client authentication certificate"

Although you seem to get the expected result, I think this isn't the ideal test scenario. I think typically such certificates are given arbitrary names, and checked on the server side if they match a whitelist of permitted certificates. Name constraints for client authentication certificates might be an unusual scenario.

A more important scenario is testing for validity as a SSL/TLS server certificate, and for that you'd use "-u V".

   -u certusage      Specify certificate usage:
                          C 	 SSL Client
                          V 	 SSL Server
                          S 	 Email signer
                          R 	 Email Recipient
                          ...

(b)
When verifying for SSL/TLS server usage, I'd expect two different tests:
- test that the embedded names match the constraints
  (you test that, by asking for general validity of the end entity certificate)

- test that the DNS name of the actual destination of a SSL/TLS connection, which presented this certificate,
  matches a permitted name
  (you don't test that)

Apparently this second test cannot be performed using certutil -V, I cannot find any parameter for that.

In order to perform this check, it's required to call API CERT_VerifyCertName. It would be nice to extend certutil to take another parameter to accept the intended hostname. If given, certutil -V would then have to call CERT_VerifyCertName, and require it to be successfull.

As of today, the only NSS tool that already contains a call to CERT_VerifyCertName is the vfyserv tool. However, the vfyserv tool requires a connection to a server, so you'd have to run selfserv, configured to use the certificate that you want to test, and then run vfyserv to connect to it.

Extending certutil seems to be the easier approach.

(c)
The second part of your tests use RFC822 names. I think you should use an email signer or recipient usage when verifying those, not the "SSL client" usage that you currently use for everything.

(d)
In your test named "Permitted email on particukar host (not subdomains), testing subdomain",
   (typo: it should be particular, not particukar)

you have:
- a CA with
    Permitted Subtree: RFC822 Name: "example.com"
    Data: Is a CA with no maximum path length.
- end entity cert with  
    RFC822 Name: "[e-mail]"

You expect and get a validation failure, which surprises me.
Can you explain why the subdomain isn't allowed?

Comment 8

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Bulk change per wleung.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.