Background on these keys is described below:
On 09/30/14 20:00, Peter Jones wrote:
> We should generate a special key that's not in our normal signing chains
> for PK and KEK. The reason for this is that [in practice] PK gets
> treated as part of DB (*).
> [Shipping a key in our normal signing chains] as PK means you can run
> grub directly, in which case it won't have access to the shim protocol.
> When grub is run without the shim protocol registered, it assumes SB is
> disabled and boots without verifying the kernel. We don't want that to
> be a thing you can do, but allowing that is the inevitable result of
> shipping with any of our normal signing chain in PK or KEK.
> (* USRT has actually agreed that since you can escalate to this behavior
> if you have the secret half of a key in KEK or PK anyway, and many
> vendors had already shipped it this way, that it is fine and I think
> even *expected* at this point, even though it wasn't formally in the
> UEFI 2.3.1 Spec that introduced Secure Boot. I'll try and make sure the
> language reflects that in an upcoming spec revision.)
> So let me get SRT to issue a special key to use for PK and KEK. We can
> use it just for those operations, and make sure it's protected with the
> same processes and controls as our other signing keys.
We include Debian and Ubuntu keys generated in this manner - i.e.,
not in our normal signing chains, and where the public key was not saved.
The Debian key was generated using the following command, taken from
commit be9470b3c9 "OvmfPkg/EnrollDefaultKeys: enroll PK/KEK1 from the Type
11 SMBIOS table":
openssl req -x509 -newkey rsa:2048 -outform PEM \
-keyout /dev/null -out PkKek1.pem