CA/Root Store Policy Archive: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
(Remove list of things we are either never going to do, are in the BRs, have been superceded by events, or which have issued filed in Github)
(These lists add no value)
Line 46: Line 46:
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005
* [[CA:CertificatePolicyV1.0|Version 1.0]] -- November 2005
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004
* [[CA:CertificatePolicyV0.4|Version 0.4]] -- March 2004
=== Items that belong in the Recommended Practices Wiki Page ===
List of items that may belong in the [[CA:Recommended_Practices | Recommended Practices]] wiki page:
* [[CA:Recommended_Practices#Publicly_Available_CP_and_CPS | CP/CPS documents:]] Further recommendations about CP/CPS documents
* [[CA:Recommended_Practices#CA_Hierarchy | CA Hierarchy:]] A hierarchical structure of a single root with intermediate/subordinate certs is preferred.
* [[CA:Recommended_Practices#Audit_Criteria | Audit Criteria:]] Further information about Audit Criteria
* [[CA:Recommended_Practices#Verifying_Domain_Name_Ownership | Domain Name Verification:]] More specific information about the requirements for verifying domain name ownership
* [[CA:Recommended_Practices#Verifying_Email_Address_Control | Email Address Verification:]] More specific information about the requirements for verifying email address ownership
* [[CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber | Verification of Identity of Code Signing Certificate Subscriber:]] More specific information about the requirements for verifying that the entity submitting the certificate signing request is the same entity referenced in the certificate, or has been authorized by the entity referenced in the certificate.
* [[CA:Recommended_Practices#OCSP | OCSP Recommendations:]] How to test OCSP in Firefox, commonly encountered error codes, etc.
* [[CA:Recommended_Practices#Notes_for_future_work | Non US-ASCII character sets in certs]]
=== Items that belong in the Potentially Problematic Practices Wiki Page ===
Items that may belong in the [[CA:Problematic_Practices | Potentially Problematic Practices]] wiki page.
* [[CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties | Delegation of Domain / Email validation to third parties:]]
* [[CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots | Issuing end entity certificates directly from roots]]
* [[CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs | Allowing external entities to operate subordinate CAs]]
* [[CA:Problematic_Practices#Distributing_generated_private_keys_in_PKCS.2312_files | Distributing generated private keys in PKCS#12 files]]
* [[CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root | OCSP Responses signed by a certificate under a different root]]
* [[CA:Problematic_Practices#CRL_with_critical_CIDP_Extension | CRL with critical CIDP Extension]]
* [[CA:Problematic_Practices#Generic_names_for_CAs | Generic names for CAs]]

Revision as of 21:10, 30 November 2016

Process for Updating the Policy

The general process that will be followed to update the Mozilla CA Certificate Policy is as follows. Issues and potential changes will be tracked in the policy issue tracker.

  1. A Mozilla representative will bring forward an item for discussion in the mozilla.dev.security.policy forum.
  2. There will be a discussion of how, if at all, to modify the policy for the item.
  3. At some point, which may be at the start, a Mozilla representative will draft proposed text.
  4. A Mozilla representative will summarize a consensus that has been reached, and/or state the official position of Mozilla in both the discussion in mozilla.dev.security.policy and in the policy issue tracker.
  5. The draft policy in Github will be updated, if required.
  6. The issue will be closed.

At intervals, a new policy version will be released based on the current draft, along with a timeline for compliance.

Previous Versions of the Policy

2.2

2.1

2.0

Earlier