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 5C1FE225B028F for ; Tue, 20 Mar 2018 07:49: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 1B28440006E6; Tue, 20 Mar 2018 14:56:13 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-203.rdu2.redhat.com [10.10.120.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3A43E11701C7; Tue, 20 Mar 2018 14:56:10 +0000 (UTC) To: Jiaxin Wu , "Fu, Siyuan" Cc: edk2-devel-01 , "Daniel P. Berrange" From: Laszlo Ersek Message-ID: <32764418-f00f-2423-216d-24b3f842a3c7@redhat.com> Date: Tue, 20 Mar 2018 15:55:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 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.5]); Tue, 20 Mar 2018 14:56:13 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Tue, 20 Mar 2018 14:56:13 +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: internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 14:49:45 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Jiaxin, Siyuan, setting *multiple* CA certificates for HTTPS server verification looks possible, from the following call tree: TlsConfigCertificate() [NetworkPkg/HttpDxe/HttpsSupport.c] TlsConfigurationSetData() [NetworkPkg/TlsDxe/TlsConfigProtocol.c] TlsSetCaCertificate() [CryptoPkg/Library/TlsLib/TlsConfig.c] X509_STORE_add_cert() because the outermost TlsConfigCertificate() function implements a loop over the EFI_TLS_CA_CERTIFICATE_VARIABLE contents. Is there natural-language documentation available about the internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE? Because, OVMF should avoid taking one format of CA Cert list from QEMU (i.e. from the virtualization host) and converting it to the format expected by TlsConfigCertificate(). Instead, the "update-ca-trust" command should be taught (on the host system) to generate a binary certificate list file (somewhere under "/etc/pki/ca-trust/extracted", I believe) such that the file can be used directly for setting EFI_TLS_CA_CERTIFICATE_VARIABLE in the guest. In order to write such an extractor for "update-ca-trust", the format of EFI_TLS_CA_CERTIFICATE_VARIABLE should be publicly documented. Also, a promise of stability wouldn't hurt. :) (To refer back to the cipher suite list discussion , this stability / public documentation goal was guaranteed there, due to EFI_TLS_CIPHER being specified publicly.) Thanks! Laszlo