Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.
== 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.
[[CA:MD5and1024|Dates for Phasing out MD5-based signatures and 1024-bit moduli]]
=== 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.
=== Validate all Data included in Certificates ===
Only data that has been verified to be correct should be included in a certificate. All information that is supplied by the requester must be verified to be correct before it may be included in the certificate. For example, for SSL certificates, alternative names need to be validated just as well as the subject. And for email certificates, if only the email address of the certificate subscriber is verified, then the CN should not include any unverified element that the subscriber supplied.
=== DNS names in SANs ===
It would be appropriate for Mozilla CA policy to mandate that CAs put all DNS names for a cert into SANs. It would not be necessary to go beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in the subject common name for the benefit of VERY old (more than 12 year old) browsers that don't recognize SANs. It is only necessary to make it clear that ALL the DNS names (not all but one) must go into the SAN.
Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. That's wrong. ALL should go into the SAN.
Then, modern browsers should stop paying attention to Subject common names ({{bug|552346}}). Doesn't matter what CAs put there as long as browsers don't look there.
