Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require the entire CA Hierarchy to be audited against each purpose the root is trusted for #220

Open
WilsonKathleen opened this issue Nov 5, 2020 · 2 comments

Comments

@WilsonKathleen
Copy link
Contributor

We would like to get to the point of having separate CA hierarchies for separate purposes, e.g. TLS (Web PKI), TLS EV, and S/MIME.

Therefore, we should add the following requirement to Mozilla's root store policy with a future effective date:

If a CA is trusted for purpose (e.g. TLS or TLS EV), then that certificate and all of its subordinate CAs should be audited against the criteria relevant for that purpose.

@dzacharo
Copy link

I was just re-reading this and realized that the first sentence seems to imply that CAs should create separate hierarchies for non-EV TLS and EV-TLS. @WilsonKathleen is that Mozilla's expectation for future Root inclusion requests?

@WilsonKathleen
Copy link
Contributor Author

I was just re-reading this and realized that the first sentence seems to imply that CAs should create separate hierarchies for non-EV TLS and EV-TLS. @WilsonKathleen is that Mozilla's expectation for future Root inclusion requests?

This is a proposal that will need to be discussed in mozilla.dev.security.policy. Separating non-EV TLS and EV-TLS into separate hierarchies would certainly simplify things. But for now it is merely a proposal to consider/discuss at a future date. If it were to be agreed on and added to a version of Mozilla's root store policy, then there would also be a future effective date, so that the rule would only apply to certificates issued after that date. That effective date and details would also have to be determined during the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants