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 On Thu, Nov 21, 2024 at 7:03 PM 'Ben Wilson' via [email protected] <[email protected]> wrote: > All, > > Currently, item 5 in section 3.3 of the MRSP > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses> > says that CPs, CPSes, CP/CPSes must be structured according to RFC 3647 > <https://datatracker.ietf.org/doc/html/rfc3647> 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 > <https://github.com/mozilla/pkipolicy/issues/263> "Clarify sentence > prohibiting blank sections that also contain no Subsections in CPs and CPSes > ”. > > Here in GitHub, lines 337 through 342 > <https://github.com/BenWilson-Mozilla/pkipolicy/commit/974a527f567a6b7180f37aeb6b6c7f35a8b647d3>, > 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 > <https://datatracker.ietf.org/doc/html/rfc3647#section-6>, 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 <https://datatracker.ietf.org/doc/html/rfc3647#section-6>; > > * 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 > <https://lists.cabforum.org/pipermail/servercert-wg/2024-May/thread.html> > 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 > > -- > 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 visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYmdU63yeC_DBxGQzQ6Wnnmy%2Bb0ow_iDyH7Xf15BDkJaw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYmdU63yeC_DBxGQzQ6Wnnmy%2Bb0ow_iDyH7Xf15BDkJaw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZquGGg-umVkTiZ%2BCAROr1ZaiJimKozXc-YTbAPFwmKjgTw%40mail.gmail.com.
