Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

[Ben Wilson]

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

[Aaron Gable]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Wayne Thayer]

On Thu, Dec 17, 2020 at 10:32 AM Aaron Gable via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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.
>
>

This all makes sense when applied to TLS certificates, but as Ben mentioned
the current language also applies to S/MIME. My instinct would be to either
do nothing to the current MRSP language, or to explicitly have it apply to
S/MIME and reference the BRs for TLS. If there is a desire to have the BR
4.9.10 language apply to S/MIME, I'd suggest we make that very clear.

- Wayne