MRSP 3.0: Issue #263: Clarify sentence prohibiting blank sections that also contain no Subsections in CPs and CPSes

[Ben Wilson]

All,

Currently, item 5 in section 3.3 of the MRSP says that CPs, CPSes, CP/CPSes must be structured according to RFC 3647 and "contain no sections that are blank and have no subsections."  This language is ambiguous because RFC 3647 contains several, differently numbered outlines. The current MRSP language also implies that a CP/CPS document cannot contain subsections, which is incorrect.  Also, numbered subsections often appear under RFC 3647 section headings. (Also, the CA/B Forum guidelines themselves slightly depart from the RFC 3647 framework in a couple of places - e.g. see https://github.com/cabforum/servercert/issues/513). This email opens up discussion of GitHub Issue #263 "Clarify sentence prohibiting blank sections that also contain no Subsections in CPs and CPSes”.

Here in GitHub, lines 337 through 342, I am suggesting that we modify item 5 in Section 3.3 of the MRSP to read something like:

5.  all CPs, CPSes, and combined CP/CPSes MUST be structured according to the common outline set forth in section 6 of RFC 3647, as may be amended by the CA/Browser Forum's TLS Baseline Requirements or its S/MIME Baseline Requirements, and MUST:

       * include at least every section and subsection defined in section 6 of RFC 3647;

       * only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and

       * contain no sections that are entirely blank, having no text or subsections;

FWIW, the TLS Baseline Requirements currently state, "The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647."  Ballot SC-74 failed to pass in the CA/B Forum's Server Certificate WG this past May based on the discussions had there and because it appears that there were unresolved questions, such as whether headers had to exactly match the text and capitalization in RFC 3647. I think we can resolve some of those issues here with a few minor edits to the proposed language.

Please provide any comments or suggestions you might have to improve this proposed resolution of Issue #263.

Thanks,

Ben

[Mike Shaver]

I like the cleanup.

How long should CAs have to update their CP/CPSes after a relevant amendment to the TBRs? Can we rely on the ballot’s effective date being appropriate, or should there be some 30-day-or-whatever backstop in the MRSP?

(I don’t see the current text as ambiguous about the permissibility of subsections, but if anyone does then cleaning it up is virtuous.)

Thanks, Ben!

Mike

--
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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYmdU63yeC_DBxGQzQ6Wnnmy%2Bb0ow_iDyH7Xf15BDkJaw%40mail.gmail.com.

[Dimitris Zacharopoulos]

Ben,

Could you please propose this exact language to the CABF SCWG in response to the failed SC-74?

DZ.

Nov 22, 2024 02:03:38 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>: