You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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.
The text was updated successfully, but these errors were encountered: