Re: internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE

["Fu, Siyuan" <siyuan.fu@intel.com>]

Hi, Laszlo

The data structure of EFI_TLS_CA_CERTIFICATE_VARIABLE is EFI_SIGNATURE_LIST and we have documented this in HTTPs Boot wiki page: https://github.com/tianocore/tianocore.github.io/wiki/HTTPS-Boot

You can refer section 31.4.1 "Signature Database" in UEFI 2.7 A for a detail description of EFI_SIGNATURE_LIST structure.


BestRegards
Fu Siyuan


> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Tuesday, March 20, 2018 10:56 PM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>; Daniel P. Berrange
> <berrange@redhat.com>
> Subject: internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE
> 
> 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
> <https://lists.01.org/pipermail/edk2-devel/2018-February/020944.html>,
> this stability / public documentation goal was guaranteed there, due to
> EFI_TLS_CIPHER being specified publicly.)
> 
> Thanks!
> Laszlo