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

Wed May 5 12:15:01 UTC 2021

Section 2.2 
<https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md#22authentication-and-connection-establishment> 
states:

/This certificate will be whitelisted explicitly and thus may be issued 
by a publicly trusted certificate authority (e.g. a certificate 
authority that follows
the baseline requirements of the CA Browser forum), by a national 
certificate authority or it can be self-signed./

I'm not sure how this relates to section 4.7 
<https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md#47dgcg-tls-server-certificates-dgcgtls> 
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.

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.

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.

Dimitris.

On 30/4/2021 9:36 π.μ., Dimitris Zacharopoulos via Servercert-wg wrote:
> Thanks Stefan for the link.
>
> From a quick review of the profiles, it appears that the OU field is 
> optional, similar to the keyEncipherment KU.
>
> 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 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.
>
>
> Thanks,
>
> DZ.
>
>
> Apr 30, 2021 02:05:44 Ryan Sleevi via Servercert-wg 
> <servercert-wg at cabforum.org>:
>
>
>
>     On Thu, Apr 29, 2021 at 5:54 PM Stefan Santesson
>     <stefan at aaa-sec.com <mailto:stefan at aaa-sec.com>> wrote:
>
>         Thank you Ryan for providing great feedback, confirming my
>         conclusions and fear.
>
>         There is no link to the announcement itself, but the
>         conclusion is incorporated in the design document:
>
>         https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md
>         <https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md>
>
>         See the last paragraph in section 4.5 "National Backend TLS
>         Client Authentication (NBtls"
>
>         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)."
>
>     Thanks Stefan!
>
>     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.)
>
>     There is no legitimate reason to create such a dependency, and
>     doing so would harm the agility, and therefore security, of the
>     Web PKI.
>
>         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.
>
>     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.
>
>     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.
>
>     _______________________________________________
>     Servercert-wg mailing list
>     Servercert-wg at cabforum.org
>     https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210505/c88fb952/attachment.html>