[Servercert-wg] Aligning the BRs with existing Browser Requirements
Ryan Sleevi
sleevi at google.com
Mon Oct 14 08:56:00 MST 2019
Glad to hear, Mike.
For what it's worth, Google is supportive of all of the above additional
Browser-imposed restrictions, both in terms of technical restrictions (e.g.
OCSP and certificatePolicies) and procedural restrictions (e.g. audit
letters and scoping). They all make sense in fulfilling the goals of robust
and secure products.
There are some implicit restrictions that I didn't get to, which might be
useful as explicit restrictions. An example of this might be the maximum
size of an RSA key; many products have defined maximums to prevent resource
exhaustion, but we haven't formalized that. 8K was, at least historically,
the limit that multiple products had, which seems totally reasonable to
support a diverse ecosystem. It might be useful if, when doing that scrub,
any technical limitations like that might also be highlighted. I totally
think that can/should be a separate ballot, but if y'all are already doing
the work, it might help to look out for any of those as well.
On Mon, Oct 14, 2019 at 11:45 AM Mike Reilly (GRC) <
Mike.Reilly at microsoft.com> wrote:
> 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/31169fc6/attachment-0001.html>
More information about the Servercert-wg
mailing list