MRSP § 3.3 Clarification re: public archiving of CPs and CPSes

[Ben Wilson]

All,

In response to CA operators' requests for clarifications on our new Mozilla Root Store Policy (MRSP) requirement that they make all of their Certificate Policies (CPs), and Certification Practices Statements (CPSes) (or combined CP/CPSes) publicly available [1], I have reached out to some CAs to clarify our intent, and I have edited the notes on the policy archive wiki page [2] to state that by December 31, 2022, "CA operators will need to maintain (in their online policy repository) all older (and available) versions of each CP and CPS (or CP/CPS), regardless of changes in ownership or control of the root CA, until the entire root CA certificate hierarchy operated in accordance with such documents is no longer trusted by the Mozilla root store." 

I also created GitHub Issue 249 [3] to track amendments to section 3.3 that will clarify this issue of policy in the next version of the MRSP--to emphasize that we expect "all" (relevant and reasonably available) CPs and CPSes to be made publicly available.

Thus, the expectation is that by the end of the year (if not before), CA operators will make diligent efforts to obtain all older versions of their CPs and CPSes and to have those publicly available along with their current CP, CPS, or combined CP/CPS.

Thanks,

Ben

[1]

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a058Z000013UmsDQAS&QuestionId=Q00166,Q00167,Q00168

[2] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive

[3] https://github.com/mozilla/pkipolicy/issues/249

[Ben Wilson]

All,

I'm wordsmithing item 7 under MRSP section 3.3.  Draft language is: "7.  Effective December 31, 2022, CA operators SHALL maintain links in their online repositories to all reasonably available historic versions of CPs and CPSes (or CP/CPSes) from the creation of included CAs, regardless of changes in ownership or control of such CAs, until the entire CA certificate hierarchies (i.e. end entity certificates, intermediate CA certificates, and cross-certificates) operated in accordance with such documents are no longer trusted by the Mozilla root store."

Ben

[Matthias van de Meent]

On Fri, Oct 14, 2022 at 8:40 PM Ben Wilson <bwi...@mozilla.com> wrote:
> All,

> I'm wordsmithing item 7 under MRSP section 3.3. Draft language is: "7. Effective December 31, 2022, CA operators SHALL maintain links in their online repositories to all reasonably available historic versions of CPs and CPSes (or CP/CPSes) from the creation of included CAs, regardless of changes in ownership or control of such CAs, until the entire CA certificate hierarchies (i.e. end entity certificates, intermediate CA certificates, and cross-certificates) operated in accordance with such documents are no longer trusted by the Mozilla root store."

I've had this thought before, but how does this hierarchy qualifier work?
I can think of a cross-signing chain in which a root cross-signs a
replacement root, which then has their own cross-signed replacement,
etc., resulting in a hierarchy of certificates of which the initial
root has long expired but newer roots (and leaf certificates) still
are trusted.

For example:

Root R1,expired
^- X-signed R2, R2 is in root store
^- X-signed R3, trust from R2
^- Intermediate CA, trust from R2 through R3, technically in
hierarchy of R2 and R1.
^- Leaf Certificate

The hierarchy of R1 still is partially trusted, but it itself is not
trusted anymore. Would the CA operator need to retain the CP/CPSes for
that R1?

Wouldn't a qualifier for "valid certificate paths" be useful here to
exclude expired and/or revoked (cross) CAs from the hierarchy?

Kind regards,

Matthias van de Meent