Policy 2.8.1: MRSP Issue #249: Clarification re: all CPs and CPSes

[Ben Wilson]

All,

This discussion thread relates to the GitHub Mozilla PKI Policy Issue #249.

Here are the currently proposed changes to item 7 of Mozilla Root Store Policy (MRSP) section 3.3:

Effective December 31, 2022, CA operators SHALL maintain links in their online repositories to all reasonably available historic older versions of each CPs and CPSes (or CP/CPSes) from the creation of included CAs, regardless of changes in ownership or control of such the root CAs, until the entire root CA certificate hierarchiesy (i.e. end entity certificates, intermediate CA certificates, and cross-certificates) operated in accordance with such documents are is no longer trusted by the Mozilla root store.

The proposed changes are meant to clarify the requirement.

Thank you,

Ben

[Jesper Kristensen]

The main difference as I read it, is a weakening of the requirement by adding "reasonably available", which effectively changes the requirement from a MUST to a SHOULD. Is that the intended interpretation?

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZn1_XF4XBQVp-eqWDC9Eke4iXX%3D774t0K%3DeHqXtOCv5w%40mail.gmail.com.

[Ben Wilson]

That's a good point. The goal of that language was to phase in the requirement, but that language will need to be modified.

Thanks,

Ben

[Matthias van de Meent]

On 15 Nov 2022 at 00:33 Ben Wilson <bwi...@mozilla.com> wrote:
> This discussion thread relates to the GitHub Mozilla PKI Policy Issue #249.
>
> Here are the currently proposed changes to item 7 of Mozilla Root Store Policy (MRSP) section 3.3:
>
> Effective December 31, 2022, CA operators SHALL maintain links in their online repositories to all reasonably available historic older versions of each CPs and CPSes (or CP/CPSes) from the creation of included CAs, regardless of changes in ownership or control of such the root CAs, until the entire root CA certificate hierarchiesy (i.e. end entity certificates, intermediate CA certificates, and cross-certificates) operated in accordance with such documents are is no longer trusted by the Mozilla root store.

I'm having trouble grasping when a CA may stop maintaining those
links. As I asked earlier in [0], when is the CA certificate hierarchy
of such documents no longer considered trusted by the Mozilla Root
Store?

It seems to me that the usage of cross-certificates would make it
highly unlikely for a whole hierarchy to become no longer trusted,
because cross-certificates for replacement roots are fairly common and
each of those grows the hierarchy of a CA and delays the expiration of
the whole hierarchy by the replacement root's lifetime.

As example:

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

Can the CPs, CPSs and CP/CPSs that cover R1 before R2 was created be
deleted? Or those that cover R1 before R3 was created?
ICA1 is trusted, as is the Leaf Certificate, and the certificates are
part of the hierarchy of R3, which is part of R2's, which is part of
R1's, right? Then isn't Leaf Certificate also part of R1's hierarchy,
thus requiring CAs to maintain the documents forever, or start a new
root without cross-certificates to any old roots?

Kind regards,

Matthias van de Meent

[0] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/JnNgyxhBiZo/m/r54RxJhLAgAJ

[Ben Wilson]

Hi Matthias,

Before I answer the questions, I think example dates need to be associated with the events in the example cited below.

Thanks,

Ben

[Matthias van de Meent]

On Fri, 18 Nov 2022 at 16:39, Ben Wilson <bwi...@mozilla.com> wrote:
>
> Hi Matthias,
> Before I answer the questions, I think example dates need to be associated with the events in the example cited below.

Hi Ben,

I've included some example years. Considering that there are no
duplicate year numbers, these should be clear enough to talk about.
Note that these are hypothetical dates; if there are issues with the
(non)existence of certain standards and/or requirements, then these
can probably be fixed by shifting and transforming all numbers to
something that does work while keeping the ordering intact.

Root R1,expired
R1 validity period: 1995-2020

. ^- X-signed R2, R2 is in root store

R2 is self-signed, validity period 2005-2030. cross-signed cert by R1
has validity period of 2005-2020

. . ^- X-signed R3, trust from R2

R3 root cert validity period: 2015-2040. cross-signed cert by R2 has
validity period: 2015-2030

. . . ^- Intermediate ICA1, trusted from R2 through R3

ICA validity period: 2021-2026

. . . . ^- Leaf Certificate

validity period: 2022-2023

Thanks, and kind regards,

Matthias van de Meent

[Ben Wilson]

Hi Matthias,

Thanks for the clarification.

So, I think the goal is (and the language might have to be modified if it isn't in alignment) that applicable policy and practice documents can be retrieved for the R1 hierarchy for the period 1995 - 2020; for the R2 hierarchy, for the period from 2005 - 2030; and for the R3 hierarchy, for the period 2015 - 2040. So, for the scenario given, they should be accessible during each root CA's certificate lifetime.

In practice, it is likely that some CAs will have a series of CP/CPS documents (version 1 ... n) over the lifetimes of multiple roots. It may be that they want to keep v.1 from 1995 still accessible after 2020, but under the given scenario, it would not be required because the cross-certificate would no longer be trusted (even though the R2 CA, itself, would be trusted by then in the root store).

If maybe I have not considered a scenario or complication, then I'm open to suggestions, and the language can be modified to make our goals more clear.

Thanks,

Ben