Module signing matches keys by comparing against the key description exactly.
However, the way the key description gets constructed got changed to be
composed of the subject name plus the certificate serial number instead of the
subject name and the subjectKeyId.  I changed this to avoid problems with
certificates that don't *have* a subjectKeyId.

Instead, if available, use the raw subjectKeyId to form the key description
and only use the serial number if the subjectKeyId doesn't exist.
Reported-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>

If hexlen is odd then function returns an error.
Use IS_ERR to check for error, otherwise invalid pointer
is used and kernel gives oops:

[  132.816522] BUG: unable to handle kernel paging request at
ffffffffffffffea
[  132.819902] IP: [<ffffffff812bfc20>] asymmetric_key_id_same+0x14/0x36
[  132.820302] PGD 1a12067 PUD 1a14067 PMD 0
[  132.820302] Oops: 0000 [#1] SMP
[  132.820302] Modules linked in: bridge(E) stp(E) llc(E) evdev(E)
serio_raw(E) i2c_piix4(E) button(E) fuse(E)
[  132.820302] CPU: 0 PID: 2993 Comm: cat Tainted: G            E
3.16.0-kds+ #2847
[  132.820302] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  132.820302] task: ffff88004249a430 ti: ffff880056640000 task.ti:
ffff880056640000
[  132.820302] RIP: 0010:[<ffffffff812bfc20>]  [<ffffffff812bfc20>]
asymmetric_key_id_same+0x14/0x36
[  132.820302] RSP: 0018:ffff880056643930  EFLAGS: 00010246
[  132.820302] RAX: 0000000000000000 RBX: ffffffffffffffea RCX:
ffff880056643ae0
[  132.820302] RDX: 000000000000005e RSI: ffffffffffffffea RDI:
ffff88005bac9300
[  132.820302] RBP: ffff880056643948 R08: 0000000000000003 R09:
00000007504aa01a
[  132.820302] R10: 0000000000000000 R11: 0000000000000000 R12:
ffff88005d68ca40
[  132.820302] R13: 0000000000000101 R14: 0000000000000000 R15:
ffff88005bac5280
[  132.820302] FS:  00007f67a153c740(0000) GS:ffff88005da00000(0000)
knlGS:0000000000000000
[  132.820302] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  132.820302] CR2: ffffffffffffffea CR3: 000000002e663000 CR4:
00000000000006f0
[  132.820302] Stack:
[  132.820302]  ffffffff812bfc66 ffff880056643ae0 ffff88005bac5280
ffff880056643958
[  132.820302]  ffffffff812bfc9d ffff880056643980 ffffffff812971d9
ffff88005ce930c1
[  132.820302]  ffff88005ce930c0 0000000000000000 ffff8800566439c8
ffffffff812fb753
[  132.820302] Call Trace:
[  132.820302]  [<ffffffff812bfc66>] ? asymmetric_match_key_ids+0x24/0x42
[  132.820302]  [<ffffffff812bfc9d>] asymmetric_key_cmp+0x19/0x1b
[  132.820302]  [<ffffffff812971d9>] keyring_search_iterator+0x74/0xd7
[  132.820302]  [<ffffffff812fb753>] assoc_array_subtree_iterate+0x67/0xd2
[  132.820302]  [<ffffffff81297165>] ? key_default_cmp+0x20/0x20
[  132.820302]  [<ffffffff812fbaa1>] assoc_array_iterate+0x19/0x1e
[  132.820302]  [<ffffffff81297332>] search_nested_keyrings+0xf6/0x2b6
[  132.820302]  [<ffffffff810728da>] ? sched_clock_cpu+0x91/0xa2
[  132.820302]  [<ffffffff810860d2>] ? mark_held_locks+0x58/0x6e
[  132.820302]  [<ffffffff810a137d>] ? current_kernel_time+0x77/0xb8
[  132.820302]  [<ffffffff81297871>] keyring_search_aux+0xe1/0x14c
[  132.820302]  [<ffffffff812977fc>] ? keyring_search_aux+0x6c/0x14c
[  132.820302]  [<ffffffff8129796b>] keyring_search+0x8f/0xb6
[  132.820302]  [<ffffffff812bfc84>] ? asymmetric_match_key_ids+0x42/0x42
[  132.820302]  [<ffffffff81297165>] ? key_default_cmp+0x20/0x20
[  132.820302]  [<ffffffff812ab9e3>] asymmetric_verify+0xa4/0x214
[  132.820302]  [<ffffffff812ab90e>] integrity_digsig_verify+0xb1/0xe2
[  132.820302]  [<ffffffff812abe41>] ? evm_verifyxattr+0x6a/0x7a
[  132.820302]  [<ffffffff812b0390>] ima_appraise_measurement+0x160/0x370
[  132.820302]  [<ffffffff81161db2>] ? d_absolute_path+0x5b/0x7a
[  132.820302]  [<ffffffff812ada30>] process_measurement+0x322/0x404
Reported-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>

As it stands, the code to generate an asymmetric key ID prechecks the hex
string it is given whilst determining the length, before it allocates the
buffer for hex2bin() to translate into - which mean that checking the result of
hex2bin() is redundant.

Unfortunately, hex2bin() is marked as __must_check, which means that the
following warning may be generated if the return value isn't checked:

	crypto/asymmetric_keys/asymmetric_type.c: In function
	asymmetric_key_hex_to_key_id:
	crypto/asymmetric_keys/asymmetric_type.c:110: warning: ignoring return
	value of hex2bin, declared with attribute warn_unused_result

The warning can't be avoided by casting the result to void.

Instead, use strlen() to check the length of the string and ignore the fact
that the string might not be entirely valid hex until after the allocation has
been done - in which case we can use the result of hex2bin() for this.
Signed-off-by: NDavid Howells <dhowells@redhat.com>

The X.509 certificate list in a PKCS#7 message is optional.  To save space, we
can omit the inclusion of any X.509 certificates if we are sure that we can
look the relevant public key up by the serial number and issuer given in a
signed info block.

This also supports use of a signed info block for which we can't find a
matching X.509 cert in the certificate list, though it be populated.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Provide better handling of unsupported crypto when verifying a PKCS#7 message.
If we can't bridge the gap between a pair of X.509 certs or between a signed
info block and an X.509 cert because it involves some crypto we don't support,
that's not necessarily the end of the world as there may be other ways points
at which we can intersect with a ring of trusted keys.

Instead, only produce ENOPKG immediately if all the signed info blocks in a
PKCS#7 message require unsupported crypto to bridge to the first X.509 cert.
Otherwise, we defer the generation of ENOPKG until we get ENOKEY during trust
validation.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Make use of the new match string preparsing to overhaul key identification
when searching for asymmetric keys.  The following changes are made:

 (1) Use the previously created asymmetric_key_id struct to hold the following
     key IDs derived from the X.509 certificate or PKCS#7 message:

	id: serial number + issuer
	skid: subjKeyId + subject
	authority: authKeyId + issuer

 (2) Replace the hex fingerprint attached to key->type_data[1] with an
     asymmetric_key_ids struct containing the id and the skid (if present).

 (3) Make the asymmetric_type match data preparse select one of two searches:

     (a) An iterative search for the key ID given if prefixed with "id:".  The
     	 prefix is expected to be followed by a hex string giving the ID to
     	 search for.  The criterion key ID is checked against all key IDs
     	 recorded on the key.

     (b) A direct search if the key ID is not prefixed with "id:".  This will
     	 look for an exact match on the key description.

 (4) Make x509_request_asymmetric_key() take a key ID.  This is then converted
     into "id:<hex>" and passed into keyring_search() where match preparsing
     will turn it back into a binary ID.

 (5) X.509 certificate verification then takes the authority key ID and looks
     up a key that matches it to find the public key for the certificate
     signature.

 (6) PKCS#7 certificate verification then takes the id key ID and looks up a
     key that matches it to find the public key for the signed information
     block signature.

Additional changes:

 (1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
     cert to be rejected with -EBADMSG.

 (2) The 'fingerprint' ID is gone.  This was primarily intended to convey PGP
     public key fingerprints.  If PGP is supported in future, this should
     generate a key ID that carries the fingerprint.

 (3) Th ca_keyid= kernel command line option is now converted to a key ID and
     used to match the authority key ID.  Possibly this should only match the
     actual authKeyId part and not the issuer as well.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Implement the first step in using binary key IDs for asymmetric keys rather
than hex string keys.

The previously added match data preparsing will be able to convert hex
criterion strings into binary which can then be compared more rapidly.

Further, we actually want more then one ID string per public key.  The problem
is that X.509 certs refer to other X.509 certs by matching Issuer + AuthKeyId
to Subject + SubjKeyId, but PKCS#7 messages match against X.509 Issuer +
SerialNumber.

This patch just provides facilities for a later patch to make use of.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Make the key matching functions pointed to by key_match_data::cmp return bool
rather than int.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

A previous patch added a ->match_preparse() method to the key type.  This is
allowed to override the function called by the iteration algorithm.
Therefore, we can just set a default that simply checks for an exact match of
the key description with the original criterion data and allow match_preparse
to override it as needed.

The key_type::match op is then redundant and can be removed, as can the
user_match() function.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Remove key_type::def_lookup_type as it's no longer used.  The information now
defaults to KEYRING_SEARCH_LOOKUP_DIRECT but may be overridden by
type->match_preparse().
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Preparse the match data.  This provides several advantages:

 (1) The preparser can reject invalid criteria up front.

 (2) The preparser can convert the criteria to binary data if necessary (the
     asymmetric key type really wants to do binary comparison of the key IDs).

 (3) The preparser can set the type of search to be performed.  This means
     that it's not then a one-off setting in the key type.

 (4) The preparser can set an appropriate comparator function.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Fix the parser cleanup code to drain parsed out X.509 certs in the case that
the decode fails and we jump to error_decode.

The function is rearranged so that the same cleanup code is used in the success
case as the error case - just that the message descriptor under construction is
only released if it is still pointed to by the context struct at that point.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

The code to free a signed info block is repeated several times, so move the
code to do it into a function of its own.  This gives us a place to add clean
ups for stuff that gets added to pkcs7_signed_info.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Add a missing static (found by checker).
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Printing in base signature handling should have a prefix, so set pr_fmt().
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>

Need to export x509_request_asymmetric_key() so that PKCS#7 can use it if
compiled as a module.
Reported-by: NJames Morris <jmorris@namei.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>

X.509 certificate issuer and subject fields are mandatory fields in the ASN.1
and so their existence needn't be tested for.  They are guaranteed to end up
with an empty string if the name material has nothing we can use (see
x509_fabricate_name()).
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

pkcs7_request_asymmetric_key() and x509_request_asymmetric_key() do the same
thing, the latter being a copy of the former created by the IMA folks, so drop
the PKCS#7 version as the X.509 location is more general.

Whilst we're at it, rename the arguments of x509_request_asymmetric_key() to
better reflect what the values being passed in are intended to match on an
X.509 cert.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>

x509_request_asymmetric_keys() doesn't need the lengths of the NUL-terminated
strings passing in as it can work that out for itself.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>

Fixes the following sparse warnings:

crypto/asymmetric_keys/pkcs7_key_type.c:73:17: warning:
 symbol 'key_type_pkcs7' was not declared. Should it be static?
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NDavid Howells <dhowells@redhat.com>

crypto/asymmetric_keys/pkcs7_key_type.c needs to #include linux/err.h rather
than relying on getting it through other headers.

Without this, the powerpc allyesconfig build fails.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid Howells <dhowells@redhat.com>

struct key_preparsed_payload should have two payload pointers to correspond
with those in struct key.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NSteve Dickson <steved@redhat.com>
Acked-by: NJeff Layton <jlayton@primarydata.com>
Reviewed-by: NSage Weil <sage@redhat.com>

Provide a generic instantiation function for key types that use the preparse
hook.  This makes it easier to prereserve key quota before keyrings get locked
to retain the new key.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NSteve Dickson <steved@redhat.com>
Acked-by: NJeff Layton <jlayton@primarydata.com>
Reviewed-by: NSage Weil <sage@redhat.com>

You can select MPILIB_EXTRA all you want, it doesn't exist ;-)

Surprised kconfig doesn't complain about that...
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>

Instead of allowing public keys, with certificates signed by any
key on the system trusted keyring, to be added to a trusted keyring,
this patch further restricts the certificates to those signed only by
builtin keys on the system keyring.

This patch defines a new option 'builtin' for the kernel parameter
'keys_ownerid' to allow trust validation using builtin keys.

Simplified Mimi's "KEYS: define an owner trusted keyring" patch

Changelog v7:
- rename builtin_keys to use_builtin_keys
Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>

Instead of allowing public keys, with certificates signed by any
key on the system trusted keyring, to be added to a trusted keyring,
this patch further restricts the certificates to those signed by a
particular key on the system keyring.

This patch defines a new kernel parameter 'ca_keys' to identify the
specific key which must be used for trust validation of certificates.

Simplified Mimi's "KEYS: define an owner trusted keyring" patch.

Changelog:
- support for builtin x509 public keys only
- export "asymmetric_keyid_match"
- remove ifndefs MODULE
- rename kernel boot parameter from keys_ownerid to ca_keys
Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>

To avoid code duplication this patch refactors asymmetric_key_match(),
making partial ID string match a separate function.

This patch also implicitly fixes a bug in the code.  asymmetric_key_match()
allows to match the key by its subtype. But subtype matching could be
undone if asymmetric_key_id(key) would return NULL. This patch first
checks for matching spec and then for its value.
Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>

Only public keys, with certificates signed by an existing
'trusted' key on the system trusted keyring, should be added
to a trusted keyring.  This patch adds support for verifying
a certificate's signature.

This is derived from David Howells pkcs7_request_asymmetric_key() patch.

Changelog v6:
- on error free key - Dmitry
- validate trust only for not already trusted keys - Dmitry
- formatting cleanup

Changelog:
- define get_system_trusted_keyring() to fix kbuild issues
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDmitry Kasatkin <dmitry.kasatkin@gmail.com>

Validate the PKCS#7 trust chain against the contents of the system keyring.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Digest the signed parts of the PE binary, canonicalising the section table
before we need it, and then compare the the resulting digest to the one in the
PKCS#7 signed content.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

The pesign utility had a bug where it was using OID_msIndividualSPKeyPurpose
instead of OID_msPeImageDataObjId - so allow both OIDs.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

The PKCS#7 certificate should contain a "Microsoft individual code signing"
data blob as its signed content.  This blob contains a digest of the signed
content of the PE binary and the OID of the digest algorithm used (typically
SHA256).
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Parse the content of the certificate blob, presuming it to be PKCS#7 format.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

The certificate data block in a PE binary has a wrapper around the PKCS#7
signature we actually want to get at.  Strip this off and check that we've got
something that appears to be a PKCS#7 signature.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Parse a PE binary to find a key and a signature contained therein.  Later
patches will check the signature and add the key if the signature checks out.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>

Provide a key type for testing the PKCS#7 parser.  It is given a non-detached
PKCS#7 message as payload:

	keyctl padd pkcs7_test a @s <stuff.pkcs7

The PKCS#7 wrapper is validated against the trusted certificates available and
then stripped off.  If successful, the key can be read, which will give the
data content of the PKCS#7 message.

A suitable message can be created by running make on the attached Makefile.
This will produce a file called stuff.pkcs7 for test loading.  The key3.x509
file should be put into the kernel source tree before it is built and
converted to DER form:

	openssl x509 -in .../pkcs7/key3.x509 -outform DER -out key3.x509

###############################################################################
#
# Create a pkcs7 message and sign it twice
#
#	openssl x509 -text -inform PEM -noout -in key2.x509
#
###############################################################################
stuff.pkcs7: stuff.txt key2.priv key2.x509 key4.priv key4.x509 certs
	$(RM) $@
	openssl smime -sign \
		-signer key2.x509 \
		-inkey key2.priv \
		-signer key4.x509 \
		-inkey key4.priv \
		-in stuff.txt \
		-certfile certs \
		-out $@ -binary -outform DER -nodetach
	openssl pkcs7 -inform DER -in stuff.pkcs7  -print_certs -noout
	openssl asn1parse -inform DER -in stuff.pkcs7  -i >out

stuff.txt:
	echo "The quick red fox jumped over the lazy brown dog" >stuff.txt

certs: key1.x509 key2.x509 key3.x509 key4.x509
	cat key{1,3}.x509 >$@

###############################################################################
#
# Generate a signed key
#
#	openssl x509 -text -inform PEM -noout -in key2.x509
#
###############################################################################
key2.x509: key2.x509_unsigned key1.priv key1.x509
	openssl x509 \
		-req -in key2.x509_unsigned \
		-out key2.x509 \
		-extfile key2.genkey -extensions myexts \
		-CA key1.x509 \
		-CAkey key1.priv \
		-CAcreateserial

key2.priv key2.x509_unsigned: key2.genkey
	openssl req -new -nodes -utf8 -sha1 -days 36500 \
		-batch -outform PEM \
		-config key2.genkey \
		-keyout key2.priv \
		-out key2.x509_unsigned

key2.genkey:
	@echo Generating X.509 key generation config
	@echo  >$@ "[ req ]"
	@echo >>$@ "default_bits = 4096"
	@echo >>$@ "distinguished_name = req_distinguished_name"
	@echo >>$@ "prompt = no"
	@echo >>$@ "string_mask = utf8only"
	@echo >>$@ "x509_extensions = myexts"
	@echo >>$@
	@echo >>$@ "[ req_distinguished_name ]"
	@echo >>$@ "O = Magrathea"
	@echo >>$@ "CN = PKCS7 key 2"
	@echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2"
	@echo >>$@
	@echo >>$@ "[ myexts ]"
	@echo >>$@ "basicConstraints=critical,CA:FALSE"
	@echo >>$@ "keyUsage=digitalSignature"
	@echo >>$@ "subjectKeyIdentifier=hash"
	@echo >>$@ "authorityKeyIdentifier=keyid"

###############################################################################
#
# Generate a couple of signing keys
#
#	openssl x509 -text -inform PEM -noout -in key1.x509
#
###############################################################################
key1.x509: key1.x509_unsigned key4.priv key4.x509
	openssl x509 \
		-req -in key1.x509_unsigned \
		-out key1.x509 \
		-extfile key1.genkey -extensions myexts \
		-CA key4.x509 \
		-CAkey key4.priv \
		-CAcreateserial

key1.priv key1.x509_unsigned: key1.genkey
	openssl req -new -nodes -utf8 -sha1 -days 36500 \
		-batch -outform PEM \
		-config key1.genkey \
		-keyout key1.priv \
		-out key1.x509_unsigned

key1.genkey:
	@echo Generating X.509 key generation config
	@echo  >$@ "[ req ]"
	@echo >>$@ "default_bits = 4096"
	@echo >>$@ "distinguished_name = req_distinguished_name"
	@echo >>$@ "prompt = no"
	@echo >>$@ "string_mask = utf8only"
	@echo >>$@ "x509_extensions = myexts"
	@echo >>$@
	@echo >>$@ "[ req_distinguished_name ]"
	@echo >>$@ "O = Magrathea"
	@echo >>$@ "CN = PKCS7 key 1"
	@echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2"
	@echo >>$@
	@echo >>$@ "[ myexts ]"
	@echo >>$@ "basicConstraints=critical,CA:TRUE"
	@echo >>$@ "keyUsage=digitalSignature,keyCertSign"
	@echo >>$@ "subjectKeyIdentifier=hash"
	@echo >>$@ "authorityKeyIdentifier=keyid"

###############################################################################
#
# Generate a signed key
#
#	openssl x509 -text -inform PEM -noout -in key4.x509
#
###############################################################################
key4.x509: key4.x509_unsigned key3.priv key3.x509
	openssl x509 \
		-req -in key4.x509_unsigned \
		-out key4.x509 \
		-extfile key4.genkey -extensions myexts \
		-CA key3.x509 \
		-CAkey key3.priv \
		-CAcreateserial

key4.priv key4.x509_unsigned: key4.genkey
	openssl req -new -nodes -utf8 -sha1 -days 36500 \
		-batch -outform PEM \
		-config key4.genkey \
		-keyout key4.priv \
		-out key4.x509_unsigned

key4.genkey:
	@echo Generating X.509 key generation config
	@echo  >$@ "[ req ]"
	@echo >>$@ "default_bits = 4096"
	@echo >>$@ "distinguished_name = req_distinguished_name"
	@echo >>$@ "prompt = no"
	@echo >>$@ "string_mask = utf8only"
	@echo >>$@ "x509_extensions = myexts"
	@echo >>$@
	@echo >>$@ "[ req_distinguished_name ]"
	@echo >>$@ "O = Magrathea"
	@echo >>$@ "CN = PKCS7 key 4"
	@echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2"
	@echo >>$@
	@echo >>$@ "[ myexts ]"
	@echo >>$@ "basicConstraints=critical,CA:TRUE"
	@echo >>$@ "keyUsage=digitalSignature,keyCertSign"
	@echo >>$@ "subjectKeyIdentifier=hash"
	@echo >>$@ "authorityKeyIdentifier=keyid"

###############################################################################
#
# Generate a couple of signing keys
#
#	openssl x509 -text -inform PEM -noout -in key3.x509
#
###############################################################################
key3.priv key3.x509: key3.genkey
	openssl req -new -nodes -utf8 -sha1 -days 36500 \
		-batch -x509 -outform PEM \
		-config key3.genkey \
		-keyout key3.priv \
		-out key3.x509

key3.genkey:
	@echo Generating X.509 key generation config
	@echo  >$@ "[ req ]"
	@echo >>$@ "default_bits = 4096"
	@echo >>$@ "distinguished_name = req_distinguished_name"
	@echo >>$@ "prompt = no"
	@echo >>$@ "string_mask = utf8only"
	@echo >>$@ "x509_extensions = myexts"
	@echo >>$@
	@echo >>$@ "[ req_distinguished_name ]"
	@echo >>$@ "O = Magrathea"
	@echo >>$@ "CN = PKCS7 key 3"
	@echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2"
	@echo >>$@
	@echo >>$@ "[ myexts ]"
	@echo >>$@ "basicConstraints=critical,CA:TRUE"
	@echo >>$@ "keyUsage=digitalSignature,keyCertSign"
	@echo >>$@ "subjectKeyIdentifier=hash"
	@echo >>$@ "authorityKeyIdentifier=keyid"

clean:
	$(RM) *~
	$(RM) key1.* key2.* key3.* key4.* stuff.* out certs
Signed-off-by: NDavid Howells <dhowells@redhat.com>

Find the intersection between the X.509 certificate chain contained in a PKCS#7
message and a set of keys that we already know and trust.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Verify certificate chain in the X.509 certificates contained within the PKCS#7
message as far as possible.  If any signature that we should be able to verify
fails, we reject the whole lot.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Find the appropriate key in the PKCS#7 key list and verify the signature with
it.  There may be several keys in there forming a chain.  Any link in that
chain or the root of that chain may be in our keyrings.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>