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

[Wayne Thayer via dev-security-policy]

On Thu, Dec 17, 2020 at 10:32 AM Aaron Gable via dev-security-policy <
dev-security-policy@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Aaron Gable via dev-security-policy]

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
> .
>
> Effective September 30, 2020, as a result of the Browser Alignment Ballot
> , section
> 4.9.10 of the CA/Browser Forum’s BaselineRequirements
>  (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.