Document Improvements
#131 - Improve terminology and style (High Priority)
Use more consistent terminology.
#227 - Clarify Meaning of "CP/CPS" (High Priority)
#184 - Change Terminology from SSL to TLS (High Priority)
#198 - Outline Policy Update Process (High Priority)
Add “This policy will be updated periodically in accordance with the Process for Updating the Root Store Policy [linked]. CAs MUST adhere to the current version of this policy.”
#138 - Make it clear that RFC6962 precertificates are covered by Mozilla policy (Medium Priority)
Mozilla doesn't currently have a policy on CT, but we consider precertificates to be a binding intent to issue as described in the RFC, and thus in-scope for our policy. Make this explicit in the policy.
SMIME Certificates
#178 - Sunset SHA-1 in S/MIME Certificates (Medium Priority)
Set a date after which SHA-1 S/MIME certificates may no longer be issued
#95 - Require CAs to blacklist keys in certs which are revoked for keyCompromise (Low Priority)
(SC35 already handled this case for server authentication certificates: https://github.com/cabforum/servercert/pull/224/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1473), but this would be for SMIME certificates, too.
Subordinate CAs / Trust Transfer
#195 - Require public discussion when an organization receives a new subCA (High Priority)
We would need to identify those CAs that have been grandfathered in without public discussion.
#228 - Clarify technically-constrained sub-CA extended key usages (High Priority)
Discourage multiple, unrelated EKUs within technically constrained sub-CAs
#229 (Pull Request) - Disclose also TCSC to CCADB (High Priority)
As discussed on the list (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/xw8JGJYZBAAJ) it seems reasonable to require technically constrained sub CAs to be disclosed in CCADB if they chain up to a root in Mozilla's root store.
#230 (Pull Request) - Clarifying Trust Transfer (High Priority)
Change “CAs SHOULD NOT assume that trust is transferable” to “CAs SHALL NOT assume that trust is transferable”
CRLs
#226 - Update the incorrect extensions item in section 5.2 (Medium Priority)
Clarify the use of AKIs in CRLs
- see
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/D7VCo-zyWk4/m/HAy-c49FBAAJ
#218 - Clarify CRL requirements for End Entity Certificates (Low Priority)
I believe this is being addressed by related work in the CCADB and by Apple. So, should this be removed from this batch of v.2.8 MRSP changes?
Audits and Auditors
#155 - Describe actions Mozilla may take upon receipt of a qualified audit (High Priority)
Set a norm in policy for the expected actions that will occur when Mozilla receives an audit containing qualifications (e.g. filing of an incident report, etc.).
#219 - Require ETSI auditors to be ACAB-c members (Medium Priority)
Involvement with the ACAB’c improves the quality of ETSI audit reports.
Additional Requirements of CAs
#185 - Require publication of outdated CA policy documents (Low Priority)
CA to maintain availability of CPs and CPSes that are applicable to CA certificate hierarchies that are currently included in the Mozilla root program.
#129 - Forbid Arbitrary Revocations (Low Priority)
Require non-discriminatory CA conduct
See https://groups.google.com/d/msg/mozilla.dev.security.policy/NjMmyA6MxN0/asxTGD3dCAAJ
#160 - Require CAs to use the CAB Forum EV Policy OID (Low Priority)
Should this requirement be removed from consideration in the v.2.8 batch of changes? (being tackled in sleevi/cabforum-docs#36 for the CABF)Subordinate CAs / Trust Transfer
#233 - Add link from Section 8 to Process for Considering Externally Operated Subordinate CAs. (“DRAFT” will be removed after review and comment.) I believe this is related to Issue #195 (Require public discussion when an organization receives a new subCA) (High Priority) For example, “Require an organization that has not previously undergone a public discussion to go through one upon receiving a new subCA”. (“Receiving a new subCA” would need to be refined with better language to address just the externally operated CAs, e.g. where the private key is externally held by a third party.)
#230 (Pull Request) - Clarifying Trust Transfer (High Priority) Edit MRSP section 8 “CAs SHOULD NOT assume that trust is transferable” to “CAs SHALL NOT assume that trust is transferable”
#229 (Pull Request) - Disclose also TCSC to CCADB (High Priority) See MDSP Discussion. It seems reasonable to require technically constrained sub CAs to be disclosed to CCADB if they chain up to a root in Mozilla's root store.
#228 - Clarify technically-constrained sub-CA extended key usages (High Priority) Discourage multiple extended key usages within technically constrained sub-CAs
Document Improvements
#131 Improve terminology and style (High Priority) Use more consistent terminology. Replace “CA” with “CA Operator” when referring to an organization. Make lists more consistent (semicolons, “and” or “or”, and bullets and numbering).
#227 Clarify Meaning of "CP/CPS" (High Priority)
#184 Change Terminology from “SSL” to “TLS” (High Priority)
#198 - Outline Policy Update Process (High Priority) Add “This policy will be updated periodically in accordance with the Process for Updating the Root Store Policy [linked]. CAs MUST adhere to the current version of this policy.”
#138 - Make it clear that RFC6962 pre-certificates are covered by Mozilla policy (Medium Priority) Mozilla doesn't currently have a policy on CT, but we consider pre-certificates to be a binding intent to issue as described in the RFC, and thus in-scope for our policy. Make this explicit in the policy by adding a new section 5.4 titled, “Pre-certificates” and paste in content from https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates.
S/MIME Certificates
#178 - Sunset SHA-1 (e.g. S/MIME Certificates) (Medium Priority) Set a date after which SHA-1 may no longer be issued for signing. Edits to be made to MRSP section 5.1.3. Question: Where is SHA-1 still being used effectively? Should SHA-1 be abolished more broadly?
#95 - Require CAs to reject keys in certificates which are revoked for keyCompromise (Low Priority) (SC35 already handled this case for server authentication certificates, but this would be for S/MIME certificates, too.)
CRLs
#226 - Update MRSP section 5.2, 6, and elsewhere, to clarify certificate and CRL profile items, e.g., the use of AKIs in CRLs, etc. (Medium Priority) See MDSP Discussion.
#218 - Clarify CRL requirements for End Entity Certificates (MediumPriority) This is a pour-over from work on MRSP version 2.7.1 and is related to work in the CCADB and by Apple. Still, we need to improve Mozilla’s statements of policy on CRLs.
#234 - Add Policy about CRL Revocation Reason Codes (Medium Priority) Mainly to flag revocations due to key compromise, but also to mark revocations for other reasons, e.g. change of affiliation, (and other reasons?).
Audits and Auditors
#155 - Describe actions Mozilla may take upon receipt of a qualified audit (High Priority)
#232 - Add Policy about removal of old Root CA certificates (Medium Priority) See current listing of 131 roots enabled for TLS/SSL Server certificate issuance. And see discussions here - CA Survey Item 8 and Item 8 Timelines.
#185 - Require publication of outdated CA policy documents (Low Priority) Amend MRSP section 3.3 to require CAs to maintain availability of CPs and CPSes that are applicable to CA certificate hierarchies that are currently included in the Mozilla root program.
#129 - Require non-discriminatory CA conduct (Medium Priority) See MDSP Discussion. Should MRSP section 2.1 be amended to require CA Operators to act in a non-discriminatory manner? (I.e. CAs should not DoS or censor websites by revoking their certificates or by refusing to issue certificates.)
#160 - Require CAs to use the CAB Forum EV Policy OID (Low Priority) Section 7.1.6.4 of the Baseline Requirements states, "Effective 2020‐09‐30, a Certificate issued to a Subscriber MUST contain, within the Certificate’s certificatePolicies extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum’s reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23)ca-browser-forum(140) certificate-policies(1)} (2.23.140.1). … Certificate Policy Identifier: 2.23.140.1.1 If the Certificate complies with these Requirements and has been issued and operated in accordance with the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates (“EV Guidelines”)." So, can Issue #160 be closed?
Thanks,
Ben
Discussion will remain open until 1-Dec-2021 #233 - Editing Process for Review and Approval of Externally Operated Subordinate CAs.
Closing Discussion #230 (Pull Request) - Clarifying Trust Transfer
MRSP section 8 “CAs SHALL NOT assume that trust is transferable”
Discussion will remain open until 1-Dec-2021 #229 (Pull Request) - Disclose also TCSC to CCADB
See MDSP Discussion. It seems reasonable to require technically constrained sub CAs to be disclosed to CCADB if they chain up to a root in Mozilla's root store.
Discussion will remain open until 1-Dec-2021 #228 - Clarify technically-constrained sub-CA extended key usages
Closed – Won’t Fix #129 - Require non-discriminatory CA conduct
Next up #235 - Require CCADB Disclosure of Full CRLs (or equivalent JSON array) for CRLite
Next up #219 - Require ETSI auditors to be ACAB-c members
Involvement with the ACAB’c improves the quality of ETSI audit reports.
Working on / Researching still #232 - Add Policy about removal of old Root CA certificates
See current listing of 131 roots enabled for TLS/SSL Server certificate issuance. And see discussions here - CA Survey Item 8 and Item 8 Timelines.
Working on / Researching still #155 - Describe actions Mozilla may take upon receipt of a qualified audit
Other issues:
Set a date after which SHA-1 may no longer be issued for signing. Edits to be made to MRSP section 5.1.3. Where is SHA-1 still being used effectively?
#95 - Require CAs to reject keys in certificates which are revoked for keyCompromise (SC35 already handled this case for server authentication certificates, but this would be for S/MIME certificates, too.)
CRLs
#226 - Update MRSP section 5.2, 6, and elsewhere, to clarify certificate and CRL profile items, e.g., the use of AKIs in CRLs, etc. See MDSP Discussion.
#218 - Clarify CRL requirements for End Entity Certificates
This poured over from work on MRSP version 2.7.1 and is related to work in the CCADB and by Apple. Still we need to improve Mozilla’s statements of policy on CRLs.
#234 - Add Policy about CRL Revocation Reason Codes
Mainly to flag revocations due to key compromise, but also mark revocations for other reasons.
Amend MRSP section 3.3 to require CAs to maintain availability of CPs and CPSes that are applicable to CA certificate hierarchies that are currently included in the Mozilla root program.
Document Improvements
#131 Improve terminology and style
Use more consistent terminology. Replace “CA” with “CA Operator” when referring to an organization. Make lists more consistent (semicolons, “and” or “or”, and bullets and numbering).
#138 - Make it clear that RFC6962 pre-certificates are covered by Mozilla policy
Mozilla doesn't currently have a policy on CT, but we consider pre-certificates to be a binding intent to issue as described in the RFC, and thus in-scope for our policy. Make this explicit in the policy by adding a new section 5.4 titled, “Pre-certificates” and paste in content from https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates.
Thanks,
Ben