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%2B1gtab1e-J0WdkO5DDJ0Shm_kuhv_6tr9ty2BU5jH_V4Ng9KA%40mail.gmail.com.

Reply via email to