From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EA18721F0DB18 for ; Thu, 29 Mar 2018 04:50:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2E59E4023141; Thu, 29 Mar 2018 11:57:23 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-223.rdu2.redhat.com [10.10.120.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5DD4A1102E2B; Thu, 29 Mar 2018 11:57:21 +0000 (UTC) To: "Palmer, Thomas" , edk2-devel-01 Cc: Ruiyu Ni , Eric Dong , Ard Biesheuvel , Jordan Justen , "Lin, Gary" , Anthony Perard , Star Zeng References: <20180328202651.1478-1-lersek@redhat.com> From: Laszlo Ersek Message-ID: Date: Thu, 29 Mar 2018 13:57:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 29 Mar 2018 11:57:23 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 29 Mar 2018 11:57:23 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list for HTTPS boot X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 11:50:46 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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