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

Mon Oct 14 08:45:43 MST 2019

Thanks for this Ryan.  My team and I are currently doing an end to end scrub of our program requirements.  Our goal is to complete this by end of October.  We’ll look through your email in detail and make any updates based on potential changes to our program requirements.  Thanks, Mike

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Saturday, October 12, 2019 10:27 AM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] Aligning the BRs with existing Browser Requirements

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...sleevi%3A2019-10-Browser_Alignment&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685550751&sdata=G%2Fy1COFJ1Qo0LLiPt7iscDCpBNoN5yZcUZehkY994F4%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsecurity%2Ftrusted-root%2Faudit-requirements%23b-the-scope-of-the-audit&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685560747&sdata=VCw5oQsDYyp4vhEtDdEd7MlREwXjrCAe3BLEKV6Yu4Y%3D&reserved=0> )
  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F%23314-public-audit-information&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685560747&sdata=Ab5C2VdksVmEHsGiWmgBGyqDTX2u1I7cwM5mQHjHwPU%3D&reserved=0> )
  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F%23314-public-audit-information&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685560747&sdata=Ab5C2VdksVmEHsGiWmgBGyqDTX2u1I7cwM5mQHjHwPU%3D&reserved=0> )
  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsecurity%2Ftrusted-root%2Faudit-requirements%23d-the-time-period-between-the-assessment-and-the-auditors-attestation&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685570743&sdata=kZE1XgEJ9up3vOs%2BiOKVBzsVbhM2iL7HDJt%2FA%2B9xvGU%3D&reserved=0> )
  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsecurity%2Ftrusted-root%2Fprogram-requirements%23c-revocation-requirements&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685570743&sdata=ryfU2pofp7sE1jqpAtjcjYpVrAp4CI2AQKKsrOBVlkA%3D&reserved=0> )
  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsecurity%2Ftrusted-root%2Fprogram-requirements%23a-root-requirements&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685580734&sdata=RxbglMNsH2lkDIVRiklkTlLXof6ekUw2T3hAphYJJ8s%3D&reserved=0> - #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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F%2353-intermediate-certificates&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685580734&sdata=vjhu%2FM8e7b20YdXyT3vEy2h%2Fvfd6t%2FT3yV6p9UxmyrI%3D&reserved=0> )
  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsecurity%2Ftrusted-root%2Fprogram-requirements%23a-root-requirements&data=02%7C01%7CMike.reilly%40microsoft.com%7Cc7527278c3534304102808d74f397fc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064980685590729&sdata=5a7oZgNKHrBk0V%2FkZXndYEZFrEzyYef9Bs%2FMWS7%2FEDY%3D&reserved=0> #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/20191014/67a92862/attachment-0001.html>