Here is an updated list: Subordinate CAs / Trust Transfer
#233 <https://github.com/mozilla/pkipolicy/issues/233> - Add link from Section 8 to Process for Considering Externally Operated Subordinate CAs <https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#DRAFT:_Process_for_Considering_Externally_Operated_Subordinate_CAs>. (“DRAFT” will be removed after review and comment.) I believe this is related to Issue #195 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/pull/230/files> (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 <https://github.com/mozilla/pkipolicy/pull/229> (Pull Request) - Disclose also TCSC to CCADB (High Priority) See MDSP Discussion <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 to CCADB if they chain up to a root in Mozilla's root store. #228 <https://github.com/mozilla/pkipolicy/issues/228> - Clarify technically-constrained sub-CA extended key usages (High Priority) Discourage multiple extended key usages within technically constrained sub-CAs Document Improvements #131 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/227> Clarify Meaning of "CP/CPS" (High Priority) #184 <https://github.com/mozilla/pkipolicy/issues/184> Change Terminology from “SSL” to “TLS” (High Priority) #198 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#513-sha-1>. Question: Where is SHA-1 still being used effectively? Should SHA-1 be abolished more broadly? #95 <https://github.com/mozilla/pkipolicy/issues/95> - Require CAs to reject keys in certificates which are revoked for keyCompromise (Low Priority) (SC35 <https://github.com/cabforum/servercert/pull/224/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1473> already handled this case for server authentication certificates, but this would be for S/MIME certificates, too.) CRLs #226 <https://github.com/mozilla/pkipolicy/issues/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 <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/D7VCo-zyWk4/m/HAy-c49FBAAJ> . #218 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/150> and #146 <https://github.com/mozilla/pkipolicy/issues/146>. #219 <https://github.com/mozilla/pkipolicy/issues/219> - Require ETSI auditors to be ACAB-c members (Medium Priority) Involvement with the ACAB’c <https://www.acab-c.com/members/> improves the quality of ETSI audit reports. Additional Requirements of CAs #232 <https://github.com/mozilla/pkipolicy/issues/232> - Add Policy about removal of old Root CA certificates (Medium Priority) See current listing of 131 roots enabled for TLS/SSL <https://ccadb-public.secure.force.com/mozilla/CACertificatesInFirefoxReport> Server certificate issuance. And see discussions here - CA Survey Item 8 <https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00141,Q00157,Q00159> and Item 8 Timelines <https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158> . #185 <https://github.com/mozilla/pkipolicy/issues/185> - Require publication of outdated CA policy documents (Low Priority) Amend MRSP section 3.3 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses> 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 <https://github.com/mozilla/pkipolicy/issues/129> - Require non-discriminatory CA conduct (Medium Priority) See MDSP Discussion <https://groups.google.com/d/msg/mozilla.dev.security.policy/NjMmyA6MxN0/asxTGD3dCAAJ>. Should MRSP section 2.1 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations> 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 <https://github.com/mozilla/pkipolicy/issues/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 On Thu, Aug 19, 2021 at 2:43 PM Ben Wilson <[email protected]> wrote: > 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 > <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 <https://github.com/mozilla/pkipolicy/issues/131> - Improve > terminology and style (High Priority) > > Use more consistent terminology. > > #227 <https://github.com/mozilla/pkipolicy/issues/227> - Clarify Meaning > of "CP/CPS" (High Priority) > > #184 <https://github.com/mozilla/pkipolicy/issues/184> - Change > Terminology from SSL to TLS (High Priority) > > #198 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/228> - Clarify > technically-constrained sub-CA extended key usages (High Priority) > > Discourage multiple, unrelated EKUs within technically constrained sub-CAs > > #229 <https://github.com/mozilla/pkipolicy/pull/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 <https://github.com/mozilla/pkipolicy/pull/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 > <https://github.com/sleevi/cabforum-docs/pull/36> for the CABF) > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaqajtGuoChYyRqj_wdRaGbvjs%3D_-0-T7aFHzvf%3Dqnkkg%40mail.gmail.com.
