[Servercert-wg] Suggestions for requirements on Certificate Consumers

[Aaron Gable]

Hi all,

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.

Also, both of these proposals build on top of Ben Wilson's proposed language
<https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md>
for requiring Certificate Consumers to publish their root program
requirements, trust store contents, etc.

Proposal 1: Certificate Consumers must run a CT log

The Certificate Transparency ecosystem is in peril at the moment. With the
recent shutdown of Sectigo's Mammoth
<https://groups.google.com/a/chromium.org/g/ct-policy/c/Ebj2hhe5QYA/m/Cl7IW33UAgAJ>
log
and retirement of DigiCert's Yeti
<https://groups.google.com/a/chromium.org/g/ct-policy/c/PVbs0ZMVeCI/m/Hf8kwuuAAQAJ>
 and Nessie
<https://groups.google.com/a/chromium.org/g/ct-policy/c/MXLJFHdHdFo> logs,
the already-tiny handful of organizations
<https://googlechrome.github.io/CertificateTransparency/log_list.html>
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.

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.

I believe that this requirement would serve multiple purposes:
- Increase the number of organizations operating CT logs
- 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)
- Further show that organizations applying as Certificate Consumers are
serious and capable of running this kind of public-benefit infrastructure

Proposal 2: Certificate Consumers must format their Root Program
Requirements per RFC 3647

The Baseline Requirements are a Certificate Policy, a document which says
*what* a given CA must do. As such, it has the standardized structure and
section headings specified by RFC 3647
<https://www.rfc-editor.org/rfc/rfc3647.html>. 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 *how*). This makes
it very easy to show exactly where a CA's CPS complies with a requirement
contained in the BRs.

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 various
<https://www.apple.com/certificateauthority/ca_program.html> root
<https://learn.microsoft.com/en-us/security/trusted-root/program-requirements>
program <https://www.chromium.org/Home/chromium-security/root-ca-policy/>
requirements
<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>
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.

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.

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.

I've prepared a very simple and minimal draft containing potential language
for these proposed requirements:
https://github.com/cabforum/forum/compare/BenWilson-SCWG-charter-1.3...aarongable:forum:patch-1

Thank you for your consideration,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20231003/7dc9b69f/attachment.html>