It has been discussed that application level trust of certificates could be individually restricted to top level domains (TLDs), for example, government roots could be restricted to issue certificates using the respective country TLDs. I've worked on an initial proof-of-concept implementation, which I'll attach to this bug. As a test, I've restricted CA "Equifax Secure CA" to the ".com" TLD. With the patch applied, you can test using the following sites: - allowed: https://www.geotrust.com/assets/images/geotrust_logo.gif - forbidden: https://kuix.de/moz.gif It reuses the existing error category "domain mismatch". It uses domain restrictions embedded in source code. Should we decide to add this functionality to core Mozilla, the following enhancements will be necessary on top of the initial patch: - individualize the error messages, in order to distinguish the classic "domain mismatch" from a "CA domain restriction violation" - make it possible for the user to edit the list of allowed/restricted TLDs (empty list = no restrictions). This could be done in the existing cert manager, by extending the "edit trust functionality". In addition to today's three trust bits, a list of TLDs could be shown, where entries could be added and removed. - potentially enhance the performance, use hashtables for lookups instead of the current nested loops of quadratic complexity
Note the implementation is not limited to TLDs, any level of domains could be specified, as a simple "search from right" test is being used to find successul matches. For example a CA could be restricted to issue certs for ".co.uk" etc.
Hm, this sounds a lot like bug 501697. Some comments: - The right error would be SEC_ERROR_CERT_NOT_IN_NAME_SPACE, the same one returned by name constraints. - It would be nice to reuse the DNS name constraint logic in NSS, which is slightly smarter than a suffix comparison: an allowed domain of "mozilla.org" matches "mozilla.org" and "bugzilla.mozilla.org" but not "foomozilla.org". The constraint could be checked either against the hostname being used, as the existing patch does, or against all hostnames on the certificate, as a name constraint on the certification path would be. The latter approach has the downside of returning more errors that are irrelevant to the connection at hand.
Whiteboard: [sg:want] → [sg:want] [psm-ca-domains]
reassign bug owner. mass-update-kaie-20120918
Assignee: kaie → nobody
We have the ability to enforce name constraints on root certificates, so I don't think there's anything more to do here.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.