Hi Ben, I added one more for the CRLs section:
+ #235 <https://github.com/mozilla/pkipolicy/issues/235>- Add Policy requiring Full CRLs (or equivalent JSON array) be disclosed in CCADB for CRLite (High Priority) Thanks, Kathleen On Friday, October 1, 2021 at 7:37:25 PM UTC-7 Ben Wilson wrote: > 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/6665d0e0-2201-47d6-8e16-3842e46bb6e8n%40mozilla.org.
