<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 5:54 PM Stefan Santesson <<a href="mailto:stefan@aaa-sec.com">stefan@aaa-sec.com</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">
  
    
  
  <div>
    <p>Thank you Ryan for providing great feedback, confirming my
      conclusions and fear.</p>
    <p>There is no link to the announcement itself, but the conclusion
      is incorporated in the design document:</p>
    <p><a href="https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md" target="_blank">https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md</a></p>
    <p>See the last paragraph in section 4.5 "National Backend TLS
      Client Authentication (NBtls"<br>
    </p>
    <p>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>Thanks Stefan!</div><div><br></div><div>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><br></div><div>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>
    <p>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>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><br></div><div>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><blockquote type="cite"><div dir="ltr"><div><div class="gmail_quote">
          </div>
        </div>
      </div>
    </blockquote>
  </div>
</blockquote></div></div>