Use X.509 extendedKeyUsage extension [RFC5280 4.2.1.12] to hold restriction
information as to the purpose of the key.  The following changes are made:

 (1) The kernel's X.509 parser is modified to extract this information and
     stash it in the public_key struct.

 (2) The kernel indicates in /proc/keys the restriction if one is found.

 (3) Autogenerated module signing key certificates are marked with a module
     signing only restriction.

The extendedKeyUsage extension takes a sequence of OIDs to indicate the set
of restricted cases.  To this end, I have assigned three OIDs in Red Hat's
OID space:

	1.3.6.1.4.1.2312.16	Kernel OIDs
	1.3.6.1.4.1.2312.16.1	- X.509 extendedKeyUsage restriction set
	1.3.6.1.4.1.2312.16.1.1	  - Firmware signing only
	1.3.6.1.4.1.2312.16.1.2	  - Module signing only
	1.3.6.1.4.1.2312.16.1.3	  - Kexecable image signing only

I would propose a fourth, key signing only, but that should perhaps be
handled through the keyUsage extension [RFC5280 4.2.1.3] setting
keyCertSign.  We might also add file signing only and IMA/Integrity signing
only restrictions.

I am treating these as mutually exclusive.  A key with a restriction is
rejected if it also gives a second restriction.


To mark a key as being for firmware signing only, for example, the "openssl
req" command can be given an extension specifier to mark the X.509
certificate.  Assuming a config script is used, this would be done by
including the following in the extension list:

	extendedKeyUsage=critical,1.3.6.1.4.1.2312.16.1.1

This adds it to the extendedKeyUsage extension.  Another, perhaps more
convenient way to do it would be to add our own extension type, eg:

	1.3.6.1.4.1.2312.16.1.1=critical,ASN1:NULL

This would easier to deal with since we examine all the extensions anyway,
and we could parameterise it, but the first option is probably the correct
way.

Also, do we need to break the firmware restriction space down by class or
manufacturer?  Or will one restriction do?
Signed-off-by: David Howells <dhowells@redhat.com>