launchpad archive-generated kmod signing keys should use extendedKeyUsage 1.3.6.1.4.1.2312.16.1.2

[Steve Langasek]

The launchpad key generation code currently generates keys with keyUsage=digitalSignature. This means that such a key, if enrolled in MOK or db in a user's UEFI firmware, would be trusted for signatures of bootloaders, kernels, and kernel modules.

In consultation with the Security Team, the constraints applied to the key used for signing of dkms modules on end-users' systems include 1.3.6.1.4.1.2312.16.1.2. As implemented in shim, this identifies the key as only to be trusted for signing of kernel modules.

As per /usr/lib/shim/mok/openssl.cnf:

# We use extended key usage information to limit what this auto-generated
# key can be used for.
#
# codeSigning: specifies that this key is used to sign code.
#
# 1.3.6.1.4.1.2312.16.1.2: defines this key as used for module signing
# only. See https://lkml.org/lkml/2015/8/26/741.
#
extendedKeyUsage = codeSigning,1.3.6.1.4.1.2312.16.1.2

Launchpad should implement this same policy for its kmod signing keys, to support granting least privilege to keys that should never be used for signing bootloaders or kernels.

(No firmware implementations are known to recognize this key usage OID; so such keys installed to db instead of MOK would still be trusted by the firmware for signing of all UEFI objects. So kmodsign keys should be registered in MOK and not in db where possible, to take advantage of this information.)

[Launchpad QA Bot (lpqabot)]

Fixed in stable r18744 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/18744>.

[Andy Whitcroft (apw)]

Threw some test builds at dogfood. Examining the public key components the kmod key has the expected extensions and the opal keys do not:

$ openssl x509 -in ~/Downloads/opal.x509 -inform DER -text | grep 'Code'
$ openssl x509 -in ~/Downloads/kmod.x509 -inform DER -text | grep 'Code'
                Code Signing, 1.3.6.1.4.1.2312.16.1.2
$