As an individual, I'd prefer that the Mozilla root program requirements incorporate the entirety of BR§4.9.10 by reference, i.e. I prefer option (2).
I prefer (2) over (1) because it makes it easier to "diff" the respective documents. Given that MRSP§6 appears to be strictly looser than BR§4.9.10, retaining both causes every reader to have to prove that fact to themselves. Incorporating by reference means readers can read a single section and know they have all the relevant information. I prefer (2) over (3) for much the same reason -- incorporating language directly (which as you say, might diverge over time) creates additional burden on readers without providing meaningful benefit. I prefer (2) over (4) because of the structure of BR§4.9.10. Namely, that "subsections (1) through (4)" is not well-defined, as there are two sets of items labeled (1) through (3). In addition, the current subsections (1) through (4) are encapsulated in a "Effective 2020-09-30" block, which suggests that the next revision of BR§4.9.10 would likely include a similar encapsulation, which may confuse the issue of "which subsections are you referring to?" even further. One potential option (5) would be to go even further than (2), and remove the OCSP paragraph from the MRSP§6 entirely. Given that MRSP§2.3 says "CA operations relating to issuance of certificates capable of being used for SSL-enabled servers MUST also conform to the latest version of the [BRs]", it seems clear that BR§4.9.10 is already included in its entirety. You could update MRSP§2.3 to say "...relating to issuance and revocation..." if you wanted to be even more explicit. Thanks, Aaron On Wed, Dec 16, 2020 at 3:46 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This discussion is related to Issue #211 on GitHub > <https://github.com/mozilla/pkipolicy/issues/211>. > > Effective September 30, 2020, as a result of the Browser Alignment Ballot > <https://cabforum.org/2020/07/16/ballot-sc31-browser-alignment/>, section > 4.9.10 of the CA/Browser Forum’s BaselineRequirements > <https://cabforum.org/baseline-requirements-documents/> (BR§4.9.10) says > that a CA’s OCSP responses must meet certain requirements. The purpose of > this email is to determine whether changes should be made to section 6 of > the Mozilla Root Store Policy > < > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation > > > (MRSP§6) to bring it closer to the Forum’s requirements for OCSP responses. > There are a few possible paths forward, including: > > *Option 1* - Leave “as is” because MRSP§6 doesn’t conflict with the > Baseline Requirements. MRSP§6 currently says, > > “For end-entity certificates, if the CA provides revocation information via > an Online Certificate Status Protocol (OCSP) service: > > · it MUST update that service at least every four days; and > > · responses MUST have a defined value in the nextUpdate field, and it MUST > be no more than ten days after the thisUpdate field; and > > · the value in the nextUpdate field MUST be before or equal to the notAfter > date of all certificates included within the BasicOCSPResponse.certs field > or, if the certs field is omitted, before or equal to the notAfter date of > the CA certificate which issued the certificate that the BasicOCSPResponse > is for.” > > *Option 2* - MRSP§6 could simply incorporate by reference all of BR§4.9.10, > but then quite a few new OCSP requirements would also be adopted, some of > which people might find useful. > > > > *Option 3* - Paste only language from BR§4.9.10’s subsections (1) through > (4) (for Subscriber/End-Entity Certificates) into MRSP§6. Those four > subsections state: “(1) OCSP responses MUST have a validity interval > greater than or equal to eight hours; (2) OCSP responses MUST have a > validity interval less than or equal to ten days; (3) For OCSP responses > with validity intervals less than sixteen hours, then the CA SHALL update > the information provided via an Online Certificate Status Protocol prior to > one-half of the validity period before the nextUpdate; and (4) For OCSP > responses with validity intervals greater than or equal to sixteen hours, > then the CA SHALL update the information provided via an Online Certificate > Status Protocol at least eight hours prior to the nextUpdate, and no later > than four days after the thisUpdate.” The drawback of this approach would > come when trying to synchronize the language—it would not be in lockstep > with relevant changes to the BRs. > > > > *Option 4* - Amend MRSP§6 to just incorporate by reference the above > subsections, i.e., “subsections (1) through (4) of BR§4.9.10, which deal > with the OCSP status responses for Subscriber Certificates, are hereby > incorporated by reference”. This approach has a similar drawback if > additional subsections are added, and it doesn’t include other language in > BR§4.9.10 that some might find useful. > > *Option 5* - Other > > Finally, under the options above, can anyone think why different language > might be needed for OCSP responses for non-SSL/TLS (e.g. SMIME) > implementations? > > Thanks in advance for your suggestions / recommendations. > > Ben Wilson > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
