[Servercert-wg] [cabfpub] Using OV TLS server certificate as TLS client certificates only

[Ryan Sleevi]

On Wed, May 5, 2021 at 8:23 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 30/4/2021 6:46 μ.μ., Ryan Sleevi wrote:
>
>
> 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.
>>
>
> 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?
>
>
> 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:
>
>    - Country Signing Certificate Authorities
>    - Gateways
>    - Trust Anchor certificates
>    - NB CSCA certificates
>    - TLS server certificates for DGCG
>    - NB TLS client certificates
>
> 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.
>

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 questions at cabforum.org list, these concerns might have been raised
sooner, but I'm hugely appreciative of Stefan bringing this to the list.

Looking at the changes made in the past view days
<https://github.com/eu-digital-green-certificates/dgc-overview/compare/e431567b3b546b3577dbe711e0983eecec875861...61ac240f74515531e221f484fa39b29a055faa05#diff-122e5821fd7db83dec9e9e106a7dfdc51a0fa640dff5bc11a1534a860973efa7>,
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.

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.

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.

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210505/db432c0c/attachment-0001.html>