Remove the fallback that loaded a raw public key from a legacy bundle's
cert field when X.509 certificate parsing failed. Previously, an attacker
could supply a bare public key in b.Cert to populate co.SigVerifier,
skipping X.509 certificate chain validation and CheckCertificatePolicy
enforcement during keyless verification. This would use the key without
any additional checks. The key-as-certificate in the bundle would take
priority over a key being provided via --key as well.
This updates the sign-blob and attest-blob code paths to never set a key
in the certificate field in the legacy bundle. Before a refactor a few
months ago, attest-blob did this. After the refactor, sign-blob did as
well. Now, neither code path will persist a key in the bundle.
For verification, verify-blob and verify-blob-attestation have been
updated to not fallback to parsing a certificate as a key. If a bundle
is supplied that contains a key, it fails with a parsing error.
Note that no change is needed for sign/attest and
verify/verify-attestation, as the container signing path never stored a
public key in the certificate field and the container verification path
would only load a certificate as a certificate.
Signed-off-by: Hayden <8418760+Hayden-IO@users.noreply.github.com>
11926fa5bb