Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/Forbidden or Problematic Practices: Difference between revisions
Jump to navigation
Jump to search
CA/Forbidden or Problematic Practices (view source)
Revision as of 10:22, 7 September 2009
, 7 September 2009no edit summary
No edit summary |
|||
| Line 62: | Line 62: | ||
Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA. | Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA. | ||
== Other considerations when updating the CA Certificate Policy == | |||
Many of the descriptions of the practices above will provide food for thought when and if we are making further updates to the CA Certificate Policy. Other issues which might be considered at that time include: | |||
=== Root Count Restrictions === | |||
It has been suggested that, when the CA cert policy is revised, we restrict the | |||
number of roots any one CA may have to e.g. 3. This is because more roots | |||
increases the download size of the product. | |||
=== Restrict government roots to their TLDs === | |||
A suggestion for a future revision of the policy is: we should restrict | |||
government run/sponsored roots to only issuing certificates for the | |||
corresponding TLD. | |||
There are, of course, questions such as: | |||
* What defines a government root | |||
* What if they have all the necessary audits anyway | |||
and so on. These would need to be discussed. | |||
=== Minimum Key Sizes === | |||
One suggestion for a future revision of the CA Cert Policy is that we should | |||
specify minimum key sizes, either just for roots or for roots, intermediates | |||
and end entity certificates. | |||
The exact restrictions would need to be discussed, but doubtless we would take | |||
into account the views of our crypto team and advice from places like NIST. | |||
=== Max Time Between Audits === | |||
It has been suggested that, when the CA cert policy is revised, we specify the | |||
maximum period allowed between audits. WebTrust currently specifies 12 months, | |||
and the same is (I understand) recommended for ETSI audits. | |||
=== Actual Paperwork === | |||
It has been suggested that CAs should submit some paperwork by postal mail as | |||
well as electronically. A formal inclusion request and general details from the | |||
CA in question might help Mozilla in the case of legal problems in the future. | |||
Apparently Apple and Microsoft do require physical paperwork. | |||
=== Improve definition of "independent"; add idea of "trustworthy" === | |||
Currently, the guidelines talk about an auditor having to be both "independent" | |||
and "competent". It has been suggested that the definition of independent | |||
should be changed to be more like that the inverse of the MPL's definition of | |||
You: | |||
"For legal entities, "You" includes any entity which controls, is controlled | |||
by, or is under common control with You. For purposes of this definition, | |||
"control" means (a) the power, direct or indirect, to cause the direction or | |||
management of such entity, whether by contract or otherwise, or (b) ownership | |||
of more than fifty percent (50%) of the outstanding shares or beneficial | |||
ownership of such entity." | |||
Additionally, a new "trustworthiness" requirement would be added, which would | |||
address some of the issues currently listed under "independent", such as being | |||
bound to render a true judgement. This is because one could imagine an auditor | |||
who was (under the above definition) independent and also competent, but may | |||
nevertheless always provide "the right result" on payment of a fee. | |||