<div dir="ltr">Hi all,<div><br></div><div>I have two proposals for requirements that the Servercert Charter could place on Certificate Consumer members. As a whole, the SCWG maintains documents that place many more requirements on Certificate Issuers than they do on Certificate Consumers. I believe that this is a good thing, dictated by the asymmetric nature of PKI ecosystems, and have no desire to change that aspect. These proposals are motivated by a desire to improve the ecosystem, not to place requirements on Certificate Consumers.</div><div><br></div><div>Also, both of these proposals build on top of <a href="https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md">Ben Wilson's proposed language</a> for requiring Certificate Consumers to publish their root program requirements, trust store contents, etc.</div><div><br></div><div>Proposal 1: Certificate Consumers must run a CT log</div><div><br></div><div>The Certificate Transparency ecosystem is in peril at the moment. With the recent <a href="https://groups.google.com/a/chromium.org/g/ct-policy/c/Ebj2hhe5QYA/m/Cl7IW33UAgAJ" target="_blank">shutdown of Sectigo's Mammoth</a> log and retirement of DigiCert's <a href="https://groups.google.com/a/chromium.org/g/ct-policy/c/PVbs0ZMVeCI/m/Hf8kwuuAAQAJ" target="_blank">Yeti</a> and <a href="https://groups.google.com/a/chromium.org/g/ct-policy/c/MXLJFHdHdFo" target="_blank">Nessie</a> logs, the already-tiny <a href="https://googlechrome.github.io/CertificateTransparency/log_list.html" target="_blank">handful of organizations</a> operating usable CT logs is feeling even smaller. The organizations running CT logs are doing a huge public service, but it is demonstrably difficult to run one well and we need more redundancy to ensure that simple mistakes and literal entropy (a single bit-flip can destroy a log!) don't leave the ecosystem high and dry.</div><div><br></div><div>So I propose that the SCWG Charter require that Certificate Consumers provide the URL of a Certificate Transparency log which operates with some SLA (e.g. 99% success with latency less than 500ms across all endpoints) and which accepts certificates which chain up to all certificates in the Certificate Consumer's root program.</div><div><br></div><div>I believe that this requirement would serve multiple purposes:</div><div>- Increase the number of organizations operating CT logs</div><div>- Ensure that every CA which is accepted in a root program has a CT log they can submit to (i.e. mitigate propagation delay with independent logs accepting new roots)</div><div>- Further show that organizations applying as Certificate Consumers are serious and capable of running this kind of public-benefit infrastructure</div><div><br></div><div>Proposal 2: Certificate Consumers must format their Root Program Requirements per RFC 3647</div><div><br></div><div>The Baseline Requirements are a Certificate Policy, a document which says <i>what</i> a given CA must do. As such, it has the standardized structure and section headings specified by <a href="https://www.rfc-editor.org/rfc/rfc3647.html">RFC 3647</a>. This has allowed many CAs to adopt a unified CP/CPS document which includes the BRs by reference and then focuses on the CPS half of the joint document (the <i>how</i>). This makes it very easy to show exactly where a CA's CPS complies with a requirement contained in the BRs.</div><div><br></div><div>In much the same way, each individual Certificate Consumer's root program requirements are a CP placing requirements on the activities of member Certificate Issuers. However, the <a href="https://www.apple.com/certificateauthority/ca_program.html">various</a> <a href="https://learn.microsoft.com/en-us/security/trusted-root/program-requirements">root</a> <a href="https://www.chromium.org/Home/chromium-security/root-ca-policy/">program</a> <a href="https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/">requirements</a> are not formatted as per RFC 3647, making it much harder to document where in the CA's CPS they commit to complying with each requirement therein.</div><div><br></div><div>So I would propose that the SCWG Charter require that Certificate Consumers' public documentation regarding their root program requirements to be formatted with the same structure and section headings as RFC 3647, i.e. the same as the BRs themselves.</div><div><br></div><div>I believe this will make it significantly easier to understand exactly where and how the individual root program requirements differ from the BRs, to track changes across versions of root program requirements, and to identify places where root programs differ (or even conflict with) each other.</div><div><br></div><div>I've prepared a very simple and minimal draft containing potential language for these proposed requirements: <a href="https://github.com/cabforum/forum/compare/BenWilson-SCWG-charter-1.3...aarongable:forum:patch-1">https://github.com/cabforum/forum/compare/BenWilson-SCWG-charter-1.3...aarongable:forum:patch-1</a></div><div><br></div><div>Thank you for your consideration,</div><div>Aaron</div></div>