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

Dimitris Zacharopoulos dzacharo at harica.gr
Fri Apr 30 06:35:59 UTC 2021

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.



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> 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, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210430/3c24e88c/attachment.html>

More information about the Servercert-wg mailing list