[cabf_validation] Revision to OU requirements

[Ryan Sleevi]

Thanks Michelle,

It sounds like you're describing a scenario that is one that is not
supported, and this may highlight a fundamental challenge.

More generally, the set of requirements on certificates are defined by
those including said certificates within their product. If a CA is subject
to additional, externally-imposed requirements, then unfortunately, they're
ineligible to be included by default within browser and operating system
products. This is to ensure the safety, security, and privacy of end users.

The need to separate out PKIs according to their requirement frameworks has
been well understood for the better part of two and a half decades; the
existence of RFC 2459 and the joint work among the ITU-T and the IETF in
the production of said document was precisely in recognition that a
singular approach to certificate hierarchies is fundamentally untenable,
and the need to operate separate hierarchies.

Luckily, the browser and operating system vendors provide an easy answer
for this, by facilitating the use of manual installation of CAs, as
appropriate to industry need. These so called "Private CAs" provide
interoperability with the browser/operating system products, if needed, and
allow the certificates issued by those private CAs to be fully exempt from
the set of requirements to be included by default.

However, for those CAs that are included by default, the existence of
additional requirements that are externally imposed, such as the implied
FERC Order 2222, are fundamentally incompatible, and the CA is ineligible
for default inclusion and subject to removal.

Normally, this is accomplished by operating two (or more) independent
hierarchies, to comply with the different operational requirements. This is
no different from manufacturing, as say, the requirements on how to
construct a dining room table, and the tools, material, and labor involved
are vastly different than the requirements on how to construct an
automobile or to operate an organic farm. Much like a "Certified Organic"
vehicle would be a concept that is difficult to imagine, so too is a
certificate that is jointly subject to multiple independent requirements
from different sectors or industries.

As the discussion here only applies to those CAs subject to the Baseline
Requirements, and to date, the only users of the Baseline Requirements are
browsers and operating systems as part of their overall approach to
determining what CAs to include by default in their product, there is no
incompatibility as you suggest. Instead, if OATI has the need to issue such
certificates, it can issue them from CAs that are not included by default
within these products, and direct their users to manually install such
certificates, in order to manually manage the trust, security, and
operational requirements.

Unfortunately, there is no acceptable path that allows for multiple
unrelated trust frameworks to be jointly combined, while still being a CA
that is included by default. This is because browser and OS vendors include
such CAs to promote the security and privacy of their users, and external
requirements that would limit this are, unfortunately, at fundamental odds.
For example, as DigiNotar has shown us, as well as nearly a decade of
subsequent CA incidents and challenges with removal of CAs, it is
critically important that browser and operating system vendors be able to
appropriately respond to their product, security, and privacy needs, as
well as that of their users.

The most obvious, and most profound, way in which one can see this
principle in action is the need to ensure prompt revocation of certificates
that were issued in violation of the Baseline Requirements. An organization
that wanted to issue certificates under joint frameworks, and which took
security seriously, would recognize that there's a fundamental risk between
the confidentiality requirements of browser and operating systems, which
necessitates prompt revocation (no greater than 5 days, although 24 hours
in others), with the critical availability requirements you've highlighted
with respect to power and energy distribution. As such, even a cursory
examination would show that such trust frameworks are already incompatible,
and the issuance of certificates for the latter is best managed by a CA
that is not part of the former.

Given this, while the use case of FERC Order 2222 is relevant with respect
to X.509 in general, it does not seem relevant to a discussion of the
Baseline Requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201016/c1bcc7eb/attachment.html>