<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 5, 2021 at 8:23 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</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>
    <br>
    <br>
    <div>On 30/4/2021 6:46 μ.μ., Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite">
      <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">
        <div> <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></div>
      </blockquote>
      <div><br>
      </div>
      <div>I'm not sure what you're referring to here? The proposal only
        covers it in two scenarios (a server certificate and a client
        certificate). Were you seeing other scenarios?</div>
    </blockquote>
    <br>
    I'm sure you read the proposal and the various components. I just
    wanted to see how different certificates are used in the design and
    in various components. The design includes:<br>
    <ul>
      <li>Country Signing Certificate Authorities</li>
      <li>Gateways</li>
      <li>Trust Anchor certificates</li>
      <li>NB CSCA certificates<br>
      </li>
      <li>TLS server certificates for DGCG <br>
      </li>
      <li>NB TLS client certificates<br>
      </li>
    </ul>
    <p>IMHO we should first try to understand how this design is
      supposed to work in order to propose changes. From a first look,
      it looks like a closed system and PTCs are not justified. However,
      we might be missing something like how the DGCs could be verified
      by anyone through the public Internet.</p></div></blockquote><div><br></div><div>I definitely appreciate your interest in finding solutions Dimitris, and I agree, if there was time available to meaningfully do so, that would be useful. Certainly, had the proponents engaged the CA/B Forum earlier, via our <a href="mailto:questions@cabforum.org">questions@cabforum.org</a> list, these concerns might have been raised sooner, but I'm hugely appreciative of Stefan bringing this to the list.</div><div><br></div><div>Looking at the changes <a href="https://github.com/eu-digital-green-certificates/dgc-overview/compare/e431567b3b546b3577dbe711e0983eecec875861...61ac240f74515531e221f484fa39b29a055faa05#diff-122e5821fd7db83dec9e9e106a7dfdc51a0fa640dff5bc11a1534a860973efa7">made in the past view days</a>, we can see Section 2.2 has been updated. The NBTLS certificate (the client certificate) has shifted from a MUST to a MAY, recognizing other options include self-signed certificates or those from national CAs. The registration is handled by the ceremony in Section 3.1 (i.e. out of band registration). The DGCG TLS (server) certificate remains unchanged, and MUST be from a Web PKI CA.</div><div><br></div><div>Unfortunately, there are still latent issues that every Web PKI CA should be aware of, because they certainly would run the risk of jeopardizing continued inclusion of that CA in root programs. Namely, the new additions to Section 2.2 recommend pinning, particularly to the leaf cert of the DGCGTLS certificate - something we know actively impairs revocation and is a frequent source of CA compliance incidents. Any CA that issues the DGCGTLS certificate should want to make it clear, as they would to any customer of theirs, that disruptions related by pinning are not a reason for the CA to ignore the Baseline Requirements, including the timeline for revocation.</div><div><br></div><div>Ideally, the DGCGTLS certificate would also be a privately-managed PKI (which includes self-signed certificates), and could be negotiated with the National Bodies during the Section 3.1 offline registration ceremony, the same way that the NB's register their NBTLS certificate with the DGCG. However, in the present state, that's not allowed, and so there's still risk that DGCG needs to ensure a fully automated, prompt replacement of certificates in the event of revocation, and realize that NB's pinning to fingerprints seriously jeopardizes the operational stability of that service.</div><div><br></div><div>As to which PKIs the relative certificates participate in, the CSCA/DSCs are explicitly stated as being modeled after the ICAO model, which is quite reasonable for this use case (hopefully including the short-lived, frequently rotated intermediate certificates, and hopefully with better linting than present in the ICAO MRTD PKI), but also not-Web PKI, nor the DGCG TA. I'm not sure why you included CSCAs twice, or "Gateways" (which is just the DGCG), but that only leaves NB TLS and DGCG TLS. The updates make it clear the NB TLS  is allowed to use not-Web PKI (which is good), even though it still allows Web PKI (which is bad; these are also pinned, via the process in Section 3.1), and the DGCG TLS is still explicitly Web PKI (and, unfortunately, pinned)</div></div></div>