<html>
<head></head>
<body> <span style="font-family:sans-serif">Thanks Stefan for the link.</span>
<br>
<br> <span style="font-family:sans-serif">From a quick review of the profiles, it appears that the OU field is optional, similar to the keyEncipherment KU.</span>
<br>
<br> <span style="font-family:sans-serif">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.</span>
<br>
<br> <span style="font-family:sans-serif">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.</span>
<br>
<br>
<br> <span style="font-family:sans-serif">Thanks,</span>
<br>
<div>
<p dir="ltr">DZ. </p>
</div>
<div>
<br>
<p>Apr 30, 2021 02:05:44 Ryan Sleevi via Servercert-wg <servercert-wg@cabforum.org>:</p>
<blockquote style="">
<div dir="ltr" style="">
<div dir="ltr" style="">
<br style="">
</div>
<br style="">
<div class="gmail_quote" style="">
<div dir="ltr" class="gmail_attr" style="">
On Thu, Apr 29, 2021 at 5:54 PM Stefan Santesson <<a href="mailto:stefan@aaa-sec.com" style="">stefan@aaa-sec.com</a>> wrote:
<br style="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="">
<p style="">Thank you Ryan for providing great feedback, confirming my conclusions and fear.</p>
<p style="">There is no link to the announcement itself, but the conclusion is incorporated in the design document:</p>
<p style=""><a href="https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md" target="_blank" style="">https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md</a></p>
<p style="">See the last paragraph in section 4.5 "National Backend TLS Client Authentication (NBtls"<br style=""> </p>
<p style="">Quote: "The TLS certificate of the NB must be issued by a publicly trusted certificate authority (included in all major browsers and operating systems, following the CAB-Forum baseline requirements)."</p>
</div>
</blockquote>
<div style="">
Thanks Stefan!
</div>
<div style="">
<br style="">
</div>
<div style="">
Yes, that's quite problematic, and several of those fields are either materially wrong (and would create security issue, such as the key usages) or are actively being discussed for deprecation (e.g. ou is being deprecated, email is outright forbidden in today's requirements in 7.1.4.2, cn cannot contain the value proposed.)
</div>
<div style="">
<br style="">
</div>
<div style="">
There is no legitimate reason to create such a dependency, and doing so would harm the agility, and therefore security, of the Web PKI.
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="">
<p style="">I'm trying to ease the burden on all poor EU countries attempting to design services connecting to this DGC. In order to upload a certificate issued by a trusted CA you need to use a TLC client authenticated session using a OV TLS certificate, and sign the certificate in a CMS signature using an upload key. This is at least 1 client key too much in my world in the first place.</p>
</div>
</blockquote>
<div style="">
Agreed. This is very much an admirable attempt at a very difficult problem, and so it's understandable that it's not perfect out of the door. Unfortunately, attempting to use the Web PKI in this way is actively harmful, fundamentally questionable with regards to security, and something that is broken today and will be further broken.
</div>
<div style="">
<br style="">
</div>
<div style="">
This is exactly where a privately managed PKI offers the full flexibility needed, and can be tailored to the specific problem, even if it requires (like all PKIs), some initial out-of-band bootstrapping. This is no different from, say, the ICAO PKD / ICAO Master List, which is perhaps an apt parallel, given the shared "passport" model being pursued. While it's encouraging to see that the CSCA and below are all managed as a private PKI, which is quite encouraging, attempting to bootstrap with the Web PKI both fails to achieve those goals and causes more harm than reasonable.
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="">
<blockquote type="cite" style="">
<div dir="ltr" style="">
<div style="">
<div class="gmail_quote" style="">
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
<div style="">
_______________________________________________
<br style="">Servercert-wg mailing list
<br style="">Servercert-wg@cabforum.org
<br style="">https://lists.cabforum.org/mailman/listinfo/servercert-wg
<br style="">
</div>
</blockquote>
</div>
</body>
</html>