<div dir="ltr"><div dir="ltr"><br></div>Moving this to the <a class="gmail_plusreply" id="plusReplyChip-9" href="mailto:servercert-wg@cabforum.org" tabindex="-1">+CA/B Forum Server Certificate WG Public Discussion List</a> since this is specific to the Baseline Requirements / Server Certificate Working Group<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 2:27 PM Stefan Santesson via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The issue is:<br>
<br>
The EU key exchange service (The DGC Gateway) will allow EU member<br>
states to uppload their DGC signing certificates for sharing among EU<br>
countries.<br>
<br>
Each country uploading DGC signing certificates must then have a TLS<br>
client certificate when connecting to the DGC Gateway.<br>
<br>
So far so good.<br>
<br>
However, today it was announced that this TLS client certificate MUST be<br>
a Organization Validation (OV) certificate issued by a public CA<br>
supported by current browsers.<br></blockquote><div><br></div><div>Could you provide a link to this announcement?</div><div><br></div><div>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.</div><div><br></div><div>This is fundamentally part of the concern previously shared with the EU, captured at <a href="https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf">https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf</a> , which explores how combining disparate trust frameworks (and, fundamentally, this is a different trust framework) harms security.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now, this is problematic, since the TLS client certificate is being used<br>
by a backend application that is NOT acting as a TLS server.</blockquote><div><br></div><div>Yes, among other reasons.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> So in order<br>
to get an OV certificate as TLS client certificate I simply need to either:<br>
<br>
1) Make a copy of the private key installed in our web server and re-use<br>
that key/certificate in my backend application as TLS client cert. </blockquote><div><br></div><div>Yes, this seems a correct understanding.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Or:<br>
<br>
2) Apply for a separate TLS Server certificate to be used as TLS client<br>
certificate. However the backend application server will NOT act as a<br>
TSL server and is not bound to any domain name (just an IP address for<br>
outbound connections).<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My guess is that both these alternatives must be some kind of violation<br>
against CAB policy for TLS server certificates.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>