<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<a moz-do-not-send="true"
href="https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md#22authentication-and-connection-establishment">Section
2.2</a> states:<br>
<br>
<i>This certificate will be whitelisted explicitly and thus may be
issued by a publicly trusted certificate authority (e.g. a
certificate authority that follows <br>
the baseline requirements of the CA Browser forum), by a national
certificate authority or it can be self-signed.</i><br>
<br>
I'm not sure how this relates to <a moz-do-not-send="true"
href="https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md#47dgcg-tls-server-certificates-dgcgtls">section
4.7</a> which describes the requirements for the DGCG TLS Server
Certificates. According to the design, the authors claim they need
publicly-trusted TLS server certificates but it's not clear to me
where the interfacing with the public relying parties is described.<br>
<br>
I was under the impression that a DGC relying party, one that would
need to verify if a DGC is valid, would be able to submit a
verification query for a specific DGC and would need to submit that
to a website protected by a PTC TLS server certificate. This makes
perfect sense to me.<br>
<br>
However, if the DGCG TLS Server Certificates are used to secure the
connection with the NB, in a "closed" environment, then it doesn't
make sense to use a PTC TLS server certificate because each
certificate will be manually "allow-listed" anyway.<br>
<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 30/4/2021 9:36 π.μ., Dimitris
Zacharopoulos via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000179217e1e2f-e69a182a-eb85-48af-a8a5-61b9eddff13a-000000@email.amazonses.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a>:</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=""
moz-do-not-send="true">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="" moz-do-not-send="true">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="">
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a> <br style="">
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a> <br
style="">
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>