Re: [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list for HTTPS boot

["Palmer, Thomas" <thomas.palmer@hpe.com>]

Sorry to miss you this time, maybe next.

Yes, I was fine the fixes but wanted to know "why". Thanks


Regards,

Thomas Palmer

“I have only made this letter longer because I have not had the time to make it shorter” - Blaise Pascal

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com] 
Sent: Thursday, March 29, 2018 6:57 AM
To: Palmer, Thomas <thomas.palmer@hpe.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>; Eric Dong <eric.dong@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Jordan Justen <jordan.l.justen@intel.com>; Lin, Gary <GLin@suse.com>; Anthony Perard <anthony.perard@citrix.com>; Star Zeng <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list for HTTPS boot

On 03/29/18 06:56, Palmer, Thomas wrote:
> Laszlo,
>
>       (First, are you are plugfest? Let's chat.)

I like chatting :) but I'm not at the plugfest. I travel only once per year, and that's to the KVM Forum.

>       Second, what need do you see for having KB worth of CA at UEFI's
>       disposal? If HTTPS feature is primarily for PXE booting OS's,
>       then it is likely the IT administrator who setup the PXE server
>       also has a single CA they want use for PXE.   By allowing any
>       and every CA to be installed (instead of having the user pick
>       only the immediately needed CAs), we inadvertently open HTTPS to
>       state-backed/well-financed malicious actors who can pay for
>       quality SSL signing services.   (The less CAs then the less that
>       can go wrong).

In a virt setup, we have to split this question in two.

(1) Why do we want to configure the guest from the host side?

(2) Why do we want to push down so many CA certs to the guest?

The answer to (1) is quite obvious: configuring the guest from the host side allows for better automation, larger scale deployment, integration with management tools etc.

Regarding (2), the premise is that the virtualization host administrator has a carefully curated set of trusted CA certificates. It does not necessarily need to be the full CA bundle from Mozilla, it just may be.
The feature that folks from our crypto and virt management tools teams are requesting is that the HTTPS configuration in the guest, for OVMF netbooting, not require *separate* administration from the host CA curation.

(The same applies to the trusted cipher suites as well, and I'm going to post patches for that too.)

>       This is not to prevent your patches going in, but would like to
>       ensure manufacturers / admins know how to properly use the CA
>       list

Oh, definitely. The idea here is *absolutely not* to encourage platform vendors (physical or virtual) to heap shady CAs into EFI_TLS_CA_CERTIFICATE_VARIABLE. This work is all about mechanism, not policy; I'm just building the conduit through wich the virt host admin can send down the CA list that they have *carefully* vetted for host-side use already. If that list contains just one certificate, so be it.

In my testing, the 182KB number comes from the default CA bundle from Mozilla (the "ca-certificates" package) on my RHEL-7 laptop, which -- as you can likely tell :) -- I haven't personally filtered down.

Thanks
Laszlo