[cabf_validation] Revision to OU requirements

[Dean Coclin]

I think it would be beneficial to have additional discussion on the OU field during the validation session at next week’s virtual face to face, with both Michelle and Ryan participating.


Clearly, the web PKI has evolved in the last 20 years and what was common practice in the past, is no longer considered a best practice. 

 

Michelle points out some of these practices, which sound like they were “baked in” to U.S. Critical Infrastructure components and a deeper understanding of their impact is warranted. 

 

Ryan indicates a potential solution is to un-trust the roots/certificates in question and have the organization manually install that trust. Without further discussion,  it’s unclear whether that would work immediately or require some sort of transition period in order to “keep the lights on”.

 

It’s unclear (and somewhat surprising) to hear that publicly trusted web PKI certificates are being used in the manner described by Michelle. But we’ve heard this before and the solution was always to transition to private roots. I’d be interested in hearing more about this (not necessarily on the list) next week.

 

Dean

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Friday, October 16, 2020 6:08 PM
To: Michelle Coon <Michelle.Coon at oati.net>
Cc: CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] Revision to OU requirements

 

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/20201017/8d6e9a59/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201017/8d6e9a59/attachment-0001.p7s>