On 09.06.20 07:09, AKASHI Takahiro wrote: > A signed image may have multiple signatures in > - each WIN_CERTIFICATE in authenticode, and/or > - each SignerInfo in pkcs7 SignedData (of WIN_CERTIFICATE) > > In the initial implementation of efi_image_authenticate(), the criteria > of verification check for multiple signatures case is a bit ambiguous > and it may cause inconsistent result. > > With this patch, we will make sure that verification check in > efi_image_authenticate() should pass against all the signatures. > The only exception would be > - the case where a digest algorithm used in signature is not supported by > U-Boot, or > - the case where parsing some portion of authenticode has failed > In those cases, we don't know how the signature be handled and should > just ignore them. > > Please note that, due to this change, efi_signature_verify_with_sigdb()'s > function prototype will be modified, taking "dbx" as well as "db" > instead of outputing a "certificate." If "dbx" is null, the behavior would > be the exact same as before. > The function's name will be changed to efi_signature_verify() once > current efi_signature_verify() has gone due to further improvement > in intermediate certificates support.
Something has been signed by a person you know and additionally by somebody you do not know. Why would the extra signature make it less trustworthy? Is this really what the UEFI spec mandates? Imagine you have an old device that needs to be updated. It only has some old db entries. As certificates expire the upstream maintainer has created a new signing certificate and signs the firmware with an old and a new certificate. Or imagine that new firmware is simply cross-signed by another party. With your rule the firmware cannot be updated. I think it is sufficient that at least one entry matches db and none matches dbx. Best regards Heinrich > > Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
