[Servercert-wg] [cabfpub] Using OV TLS server certificate as TLS client certificates only

[Ryan Sleevi]

On Fri, Apr 30, 2021 at 2:36 AM Dimitris Zacharopoulos <dzacharo at harica.gr>
wrote:

> From a quick review of the profiles, it appears that the OU field is
> optional, similar to the keyEncipherment KU.
>

As a practical matter, *any* attempts to curtail, subprofile, or extend the
Web PKI profile is problematic.

Consider the very real scenario we saw during a Certain Large CA's
deprecation, where customers were using OV certificates, and from CA A,
they contained a specific value. When these customers migrated to CA B, CA
B did not use the same O value as CA A, because of the use of a different
datasource for validation as well as different CA policies, and this
actively broken the Subscriber's products (somewhat badly), due to
"Organizational pinning". That's an example of a field that's required
here, but the reality is that the contents of that field, same as any of
the other DN fields, cannot and must not be profiled by the
Applicant/Subscriber. When we consider "optional" fields, we've all seen
the questions come in to the questions@ list that are of some form "CA A
did X for me, but CA B won't, please tell CA B they're wrong", and so for
CAs that, say, choose not to issue the OU field (as some thankfully have),
they're either unable to issue such certificates, forced to expend support
effort explaining to the customer that it is, in fact,  optional, or
inclined to go ahead and change their policies again, because someone asked.

None of this is sustainable nor reasonable, and as currently proposed,
represents a fundamental misunderstanding of the trust framework that the
Web PKI operates. For client certificates, this is entirely unreasonable,
because there's zero technical reason to use the Web PKI for client
certificates. And, for server certificates, the only thing that is reliably
consistent among all CAs is the subjectAltName, as all Subject fields are
inherently (by CAs' design, and in keeping with the misguided X.500 view),
subjective to the CA issuing them.

I think the design contains several components that need to be analyzed
> independently to see where the Publicly Trusted Certificates apply, for
> which components and for which functions.
>

I'm not sure what you're referring to here? The proposal only covers it in
two scenarios (a server certificate and a client certificate). Were you
seeing other scenarios?


> I will try to review it better next week. The pandemic has caused
> unprecedented challenges so we should take that into consideration. Not
> everyone is super familiar with the nuances of the WebPKI and often try to
> rely on an existing Publicly Trusted framework, due to time constraints,
> rather than bootstrapping a new one. This is not always a successful path
> but has worked and still works fairly well in some use cases for client
> authentication.
>

I think this is misleading, because the issue consistently is the "It
works, until it doesn't", and the "until it doesn't" is a piece of
technical debt that is catastrophically unprepared for. Our goal is to
avoid that scenario in the first place, rather than couch it in warnings
that will be ignored.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210430/f631f9fc/attachment.html>