Policy 2.8: MRSP Issue #227: Clarify Meaning of "CP/CPS"

[Ben Wilson]

Greetings,

This email introduces discussion of another issue selected to be addressed in the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8)

This is Issue #227.

The MRSP uses the terms “CP/CPS” and also “CP and CPS” and “CP or CPS”.

According to RFC 3647 and X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements."

Also, according to RFC 3647, a certification practices statement (CPS) is a "more detailed description of the practices followed by a CA in issuing and otherwise managing certificates", and “also describe practices relating to all certificate lifecycle services (e.g., issuance, management, revocation, and renewal or re-keying),” and CPSes provide details concerning other business, legal, and technical matters.

(Some CAs publish a combined CP-CPS.)

More often, the stated requirements are found in a CP, while a CPS describes how such requirements are met. Thus, a CA’s CPS is the more likely candidate, and preference or emphasis should be placed in the MRSP on the CPS as the location for a CA’s statements of how it meets Mozilla’s requirements.

Currently, MRSP section 3.3 states, “We rely on publicly disclosed documentation (e.g., in a Certificate Policy and Certification Practice Statement) to ascertain that our requirements are met.”  MRSP section 3.3 goes on to say, “the publicly disclosed documentation [must] provide[] sufficient information for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests;” (emphasis added).

Here is a first draft redline to address this Issue #227:  https://github.com/BenWilson-Mozilla/pkipolicy/commit/a7b53420d5ab9edd347ff16dfdf4448dc4af9ed7

In a couple places in MRSP section 3.3, I replaced "CP/CPS" with "the documentation" since we're talking about "the publicly disclosed documentation".

For MRSP section 2.2, one approach would be to replace “CP/CPS” with “the CPS (or, if applicable, the CP or CP/CPS)”.  Or that phrase could even be re-written to say “the CPS (or, if applicable, the CP or combined CP-CPS)” (the goal of this latter approach would be to replace "CP/CPS" in the MRSP).

Thoughts?

Thanks,

Ben

[Moudrick M. Dadashov]

Good question. I think CP/CPS issue is directly related to the terms "audit scope" and "audit criteria" used in the requirements to audit locations "included in the scope of the audit or should have been included in the scope of the audit, whether the inspection was physically carried out in person at each location, and which audit criteria were checked (or not checked) at each location".

Even though CP/CPS is a merged document, we need to clarify which sections of this document:

1) constitute a CP;

2) are subject to "audit criteria" check.

Thanks,

M.D.

Sent from my Galaxy

--
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%2B1gtaZKyrmXNcf5_cTsdKLoGC7_TRR%2Bd49i9Khf0b%2BMZ-tvFg%40mail.gmail.com.

[Ben Wilson]

All,

A comment about proposed changes to MRSP Section 3.3 (CPs and CPSes) got me thinking about the following:

 

1- Should item 2. be amended to read: "the publicly disclosed documentation MUST be available from the CA operator’s official website or saved as an attachment in Bugzilla" ?  (Often, CA operators will upload documentation to Bugzilla.)

2 - Should item 3. be amended to read "the publicly disclosed documentation MUST be made available to Mozilla under one of the following Creative Commons licenses (or later versions): ..."?  In other words, is the scope of "documentation" too broad? Should this be changed back to something more narrow like, "CPs, CPSes, and combined CP/CPSes MUST be made available ....")

3 - Should item 4. be amended to read "the CP and CPS, or the combined CP/CPS, MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements." ?  The currently proposed "documentation" might be too broad because the Baseline Requirements uses the phrase "annually update a Certificate Policy and/or Certification Practice Statement".  (Here, implementing the conjunctions "and" and "or" get messy.) Currently, the MRSP v. 2.7.1 uses the phrase "CPs and CPSes MUST be reviewed and updated...".

Thanks,

Ben

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/61b944a1.1c69fb81.f84f3.05b4SMTPIN_ADDED_MISSING%40mx.google.com.

[Ryan Sleevi]

On Fri, Mar 25, 2022 at 4:32 PM Ben Wilson <bwi...@mozilla.com> wrote:

1- Should item 2. be amended to read: "the publicly disclosed documentation MUST be available from the CA operator’s official website or saved as an attachment in Bugzilla" ?  (Often, CA operators will upload documentation to Bugzilla.)

They do, but it's just as relevant to the relying public that they should be able to get it directly from the CA, right? The Bugzilla is just a means to a particular technical end, while the disclosure on the CA operator's website is the public transparency and accountability.

 

2 - Should item 3. be amended to read "the publicly disclosed documentation MUST be made available to Mozilla under one of the following Creative Commons licenses (or later versions): ..."?  In other words, is the scope of "documentation" too broad? Should this be changed back to something more narrow like, "CPs, CPSes, and combined CP/CPSes MUST be made available ....")

No? The broad scope was intended (related to ensuring that Mozilla could make available - including via Bugzilla and/or CCADB - documents relevant to the trustworthiness of the CA.

 

3 - Should item 4. be amended to read "the CP and CPS, or the combined CP/CPS, MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements." ?  The currently proposed "documentation" might be too broad because the Baseline Requirements uses the phrase "annually update a Certificate Policy and/or Certification Practice Statement".  (Here, implementing the conjunctions "and" and "or" get messy.) Currently, the MRSP v. 2.7.1 uses the phrase "CPs and CPSes MUST be reviewed and updated...".

Maybe "All CPs, CPSes, and combined CP/CPSes, MUST be reviewed"... basically, trying to avoid the and/or combination (that often trips folks ups) by ensuring it's a cohesive list

I'm a bit more on the fence of naming explicitly the CPS, since the CP is just as relevant for ascertaining policy being met. For example, it's the policy that would detail validation requirements or certificate profiles, and while the practice statement describes how they ensure those requirements are met, the policy is just as much a relevant part. In a world of distinct CPs and CPSes, both would still need to be assessed for compliance and adherence. I realize you're far more versed in this from the ABA PAG days, but the argument for CPS would seem more relevant if Mozilla was dictating the CP, and the CPS was the CA's demonstration of how they fulfill that (i.e. the originally anticipated CP/CPS model), but that's not quite how things work today, so it seems easier to be flexible about.