Policy 2.8: Candidate Issues to Address in MRSP v. 2.8

[Ben Wilson]

All,

Below are listed the Mozilla Root Store Policy (MRSP) issues currently slated to be addressed in the next version (2.8) of the MRSP. (In GitHub, related to the MRSP, there are currently 58 issues and 2 pull requests:  https://github.com/mozilla/pkipolicy.) I've previously flagged 18 items to consider for this version 2.8 policy update. They are tagged with a "2.8" label in GitHub (https://github.com/mozilla/pkipolicy/labels/2.8). I will appreciate your input on the list below. Are there MRSP issues that should be added, removed, or re-prioritized? (The priorities were determined intuitively.) Please respond here on the dev-security-policy (MDSP) list with general comments or with pointers to the issue as it appears on GitHub. Please try to do this by 6-Sept-2021.

Also, prior to my formal posting of the final issues list, if you would like to begin in-depth, substantive discussions on the resolution of any of these issues, or introduce new issues, you can do so on GitHub. Based on your input, we will develop language to address the selected issues, and then we will start a separate discussion thread on this MDSP list for each issue. In other words, feel free to discuss these issues on GitHub until we launch a specific discussion here on this list (which will be done with a subject line of, e.g., "Policy 2.8: MRSP Issue #131", etc.).

Thanks,

Ben

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)

[Ben Wilson]

Here is an updated list:

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)

Set a norm in policy for the expected actions that will occur when Mozilla receives an audit containing qualifications (e.g. filing of incident report(s), remediation, etc.). Other related issues for reference are #150 and #146.

#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

#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

[Kathleen Wilson]

Hi Ben,

I added one more for the CRLs section:

+ #235 - Add Policy requiring Full CRLs (or equivalent JSON array) be disclosed in CCADB for CRLite (High Priority)

Thanks,

Kathleen

[Ben Wilson]

All,

Here is the updated status of where we are on the list of issues to resolve in version 2.8 of the Mozilla Root Store Policy.

 

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

Set a norm in policy for the expected actions that will occur when Mozilla receives an audit containing qualifications (e.g. filing of incident report(s), remediation, etc.). Other related issues for reference are #150 and #146.

Other issues:

 

S/MIME Certificates

 

#178 - Sunset SHA-1 (e.g. S/MIME Certificates)

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.

 

Additional Requirements of CAs

 

#185 - Require publication of outdated CA policy documents

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).

 

#227    Clarify Meaning of "CP/CPS"

 

#184    Change Terminology from “SSL” to “TLS”

 

#198 - Outline Policy Update Process

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

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