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

[Ryan Sleevi]

On Thu, Apr 29, 2021 at 5:54 PM Stefan Santesson <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
>
> 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.

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