[Servercert-wg] Aligning the BRs with existing Browser Requirements

[Ryan Sleevi]

In order for Browsers to have reasonable confidence in CAs, it is important
to ensure that, when possible, browser requirements are enshrined within
the relevant audit criteria. This helps provide independent assurance that
things are fairly stated. The best way to do that is to ensure they're
captured within the Baseline Requirements, so those can inform the
development of the audit criteria.

In order to make it easier for CAs to meet Browser root program
requirements, it is useful to ensure those requirements are captured in the
Baseline Requirements, where possible. This helps highlight the importance
of the requirement, as well as provides the opportunity for feedback and
discussion with auditors during the design and implementation process.

To that end, I've tried to capture some of the existing root program
requirements that go "above and beyond" what the BRs require, but are
never-the-less root program requirements and required by all CAs trusted by
those root programs to follow, to help reduce the divergences.

https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment
contains changes to hopefully make it easier to migrate these Root Program
requirements to the BR, now that they've been successfully implemented by
nearly all CAs in this Forum and all CAs in those browser root programs.
I've based it on the current versions, which means there's some slight
interactions with SC23, the draft cleanup ballot, and Jos' formatting
ballot - so I can appreciate that it's not quite ready to kick off to
Ballot, but hopefully sufficient to start discussion now.

The requirements on Audit Report content are updated to align with the
requirements placed by Mozilla and Microsoft.

   - Microsoft requires that the full hierarchy be documented (
   https://docs.microsoft.com/en-us/security/trusted-root/audit-requirements#b-the-scope-of-the-audit
    )
   - Mozilla requires that the intermediate(s) be documented (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information
    )
   - Mozilla requires an English language report be made available (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information
    )
   - This updates Section 8.6 to capture and combine these requirements.

The requirements on Audit Report delivery are updated to align with the
requirements placed by Microsoft.

   - The (existing) BRs place a SHOULD requirement on 3 months between the
   production of the Audit Report, in Section 8.6
   - Microsoft places a MUST requirement (
   https://docs.microsoft.com/en-us/security/trusted-root/audit-requirements#d-the-time-period-between-the-assessment-and-the-auditors-attestation
    )
   - This updates Section 8.6 to reflect this.
   - Note: This is particularly important for the oversight of
   independently-operated Sub-CAs; the objective is to ensure that the Root CA
   is receiving reports from the Subordinate, much like the Browser ensures
   they receive timely reports from the Root. Just like a failure to provide
   timely reports is a matter of non-compliance for Browsers, Roots should
   treat a failure by their intermediates to provide timely reports as matters
   of non-compliance.

The requirements on OCSP responses are updated to align with the
requirements placed by Microsoft.

   - Microsoft places additional requirements on both the minimum and
   maximum time for OCSP responses (
   https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#c-revocation-requirements
    )
   - This aligns 4.9.10 with Microsoft's requirements (This is also why the
   conflict with both SC23 and the Cleanup ballot)
   - Note: As with everything date-based, "math is hard". This attempts to
   provide an unambiguous requirement to address issues like leap-seconds and
   partial days. Feedback is most definitely welcome and needed here.


The requirements on certificatePolicies for Subscriber Certificates are
updated to align with the requirements placed by Microsoft.

   - Microsoft places a requirement on Subscriber certificates (strangely
   enough, in their Root Certificate section) that they MUST contain one of
   the CA/Browser Forum reserved OIDs (
   https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements
-
   #15)
   - This updates the BRs, 7.1.6.4, to capture this. Rather than
   referencing EV from the BRs directly, this only places a requirement that
   there MUST be one cabforum-defined OID here. This allows other
   ServerCert-WG documents (like the BRs) to extend the BRs / layer on top,
   without having to update the BRs and without having to make the EVGs
   provide an *exception* to the BRs (exceptions are bad).
   - If folks feel this approach is confusing, then I think the better
   alternative would simply be to reference the EVGs from the BRs
   (Specifically, Section 7.1.6.1), and allow that OID. I have language to do
   this, so we can totally see how folks feel it is on being completely
   unambiguous and completely unlikely to be exploited/exploitable.

The requirements on extendedKeyUsage for Subordinate CA Certificates are
updated to align with the requirements placed by Microsoft and Mozilla.

   - The BRs currently leave extKeyUsage for sub-CAs as optional.
   - Mozilla requires it for all newly issued (since 2019-01-01) sub-CAs
   that are not also Cross Certificates (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates
    )
   - Microsoft has required separation of intermediate since July 2016 for
   all sub-CAs (
   https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements
#11
   )
   - This attempts to update 7.1.2.2 (g) to reflect the intersection of
   Mozilla and Microsoft.
   - It tries to account for the following scenarios:
      - Subordinate CAs that are Cross Certificates
      - Subordinate CAs that are used to issue TLS
      - Subordinate CAs that are used to issue not-TLS (e.g. S/MIME)
      - Subordinate CAs that are used for OCSP Signing or Timestamping
   - One challenge, that we've long known since our discussions in
   governance, is different WGs potentially placing conflicting requirements
   on the same set of certificates. We've long discussed the presumed method
   of de-conflicting those situations - by ensuring only certificates
   containing the EKU relevant to the Chartered WG are in scope - but we know
   that's a large effort. I've attempted to thread that needle carefully, but
   if folks are concerned with the "For Subordinate CA Certificates that are
   not used to issue TLS certificates" paragraph, then I can tackle the
   clarity differently, by modifying Section 1.1 on scoping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191012/491a2851/attachment-0001.html>