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

[Ryan Sleevi]

Moving this to the +CA/B Forum Server Certificate WG Public Discussion List
<servercert-wg at cabforum.org> since this is specific to the Baseline
Requirements / Server Certificate Working Group

On Thu, Apr 29, 2021 at 2:27 PM Stefan Santesson via Public <
public at cabforum.org> wrote:

> The issue is:
>
> The EU key exchange service (The DGC Gateway) will allow EU member
> states to uppload their DGC signing certificates for sharing among EU
> countries.
>
> Each country uploading DGC signing certificates must then have a TLS
> client certificate when connecting to the DGC Gateway.
>
> So far so good.
>
> However, today it was announced that this TLS client certificate MUST be
> a Organization Validation (OV) certificate issued by a public CA
> supported by current browsers.
>

Could you provide a link to this announcement?

Such a thing would be fundamentally problematic to the security and
stability of TLS, and SHOULD NOT be done. More specifically, the use of Web
PKI certificates for Mutual TLS is inherently risky, because it exacerbates
the well-known issues affecting agility, revocation, and certificate
profiles, in ways that meaningfully hinder and undermine security
improvements.

This is fundamentally part of the concern previously shared with the EU,
captured at
https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf
, which explores how combining disparate trust frameworks (and,
fundamentally, this is a different trust framework) harms security.


> Now, this is problematic, since the TLS client certificate is being used
> by a backend application that is NOT acting as a TLS server.


Yes, among other reasons.


> So in order
> to get an OV certificate as TLS client certificate I simply need to either:
>
> 1) Make a copy of the private key installed in our web server and re-use
> that key/certificate in my backend application as TLS client cert.


Yes, this seems a correct understanding.


> Or:
>
> 2) Apply for a separate TLS Server certificate to be used as TLS client
> certificate. However the backend application server will NOT act as a
> TSL server and is not bound to any domain name (just an IP address for
> outbound connections).
>

This doesn't seem to make a lot of sense, though. If the expectation is
that the DGC will be doing a form of relying on the (unreliable) OV data,
without making use of the subjectAltNames expressed, then yes, this is
inherently problematic.

My guess is that both these alternatives must be some kind of violation
> against CAB policy for TLS server certificates.


Presently, the inclusion of id-kp-clientAuth is a MAY for server
certificates, and so it's not outright a violation. While I do not claim to
speak for the entire Forum, there have been multiple discussions in the
Forum in the past about removing that allowance, such that server
certificates *only* contain id-kp-serverAuth.

The purpose of including clientAuth, for server to server authentication,
is understandable as to why it might be desirable, but fundamentally
introduces a different trust framework. As we've seen with the recent
discussion about the sunset of the OU field, relying parties that build
reliance on fields other than those covered by the core BRs (i.e. the SAN)
can easily end up building insecure or non-agile systems. For example, the
inability to promptly revoke certificates (due to the impact on S2S), the
inability to migrate or replace certificates (due to lack of automation on
the client side, or assumptions about the profile that are not correct on
the server side), and even for CAs, the inability to migrate issuance
profiles and practices (e.g. transitioning to a new intermediate or root)
are all practical examples of how such S2S assumptions are fundamentally
problematic. This has been discussed further in the context of deprecations
like SHA-1, RSA-1024, and even underscores, in which S2S usecases were seen
as blocking for these necessary security efforts.

You're absolutely correct that this raises serious concern, and so if you
can provide any further details, I think it'd also provide the
opportunities for members, such as OS and browser vendors, to also provide
feedback directly as to the impact and serious security and agility
concerns this proposal raises.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210429/2a8bfe1c/attachment.html>