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

[Laszlo Ersek <lersek@redhat.com>]

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