public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com, keyrings@linux-nfs.org,
	linux-security-module@vger.kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH06/17] PKCS#7: Verify internal certificate chain
Date: Thu, 10 Jul 2014 21:37:37 +0100	[thread overview]
Message-ID: <30205.1405024657@warthog.procyon.org.uk> (raw)
In-Reply-To: <42827.1405012013@turing-police.cc.vt.edu>

Valdis.Kletnieks@vt.edu wrote:

> > 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.
> 
> What happens if we see a signature that we shouldn't be able to verify?  Or
> should that changelog entry be reduced to "If any signature fails", period?

No.

When I say "any signature that we should be able to verify" I mean that a
signature for which we have an appropriate public key.

If we don't have a public key for a signature, we prune the trust chain at
that point.

What I mean is that the PKCS#7 message can have several signatures applied to
it.  We can form a chain from each signature going back through the X.509
certificates included in the PKCS#7 message:

	PKCS#7 ---> X.509 ---> X.509 ---> X.509 ---> X.509

where the PKCS#7 message and each X.509 cert has a signature that the next
X.509 cert in the chain can be used to verify with the public key contained
therein.

Any of the signatures in any of the chains can form an intersection point with
the keyring of public keys provided.  If there's a verified match on one or
more of them, we permit the message.

If any "Y ---> X.509" verification is rejected, we reject the whole message
because there's something wrong.  If an intersection point verification is
rejected, again we reject the whole message.

If there are no intersection points, we also reject the message, but with
ENOKEY rather than EKEYREJECTED.

David

  reply	other threads:[~2014-07-10 20:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09 15:15 [PATCH 00/17] KEYS: PKCS#7 and PE file signature checking for kexec David Howells
2014-07-09 15:15 ` [PATCH01/17] X.509: Add bits needed for PKCS#7 David Howells
2014-07-09 15:15 ` [PATCH02/17] X.509: Export certificate parse and free functions David Howells
2014-07-09 15:15 ` [PATCH03/17] PKCS#7: Implement a parser [RFC 2315] David Howells
2014-07-09 15:15 ` [PATCH04/17] PKCS#7: Digest the data in a signed-data message David Howells
2014-07-09 15:15 ` [PATCH05/17] PKCS#7: Find the right key in the PKCS#7 key list and verify the signature David Howells
2014-07-09 15:16 ` [PATCH06/17] PKCS#7: Verify internal certificate chain David Howells
2014-07-10 17:06   ` Valdis.Kletnieks
2014-07-10 20:37     ` David Howells [this message]
2014-07-09 15:16 ` [PATCH07/17] PKCS#7: Find intersection between PKCS#7 message and known, trusted keys David Howells
2014-07-09 15:16 ` [PATCH08/17] PKCS#7: Provide a key type for testing PKCS#7 David Howells
2014-07-09 15:16 ` [PATCH09/17] KEYS: X.509: Fix a spelling mistake David Howells
2014-07-09 15:16 ` [PATCH10/17] Provide PE binary definitions David Howells
2014-07-09 15:16 ` [PATCH11/17] pefile: Parse a PE binary to find a key and a signature contained therein David Howells
2014-07-09 15:16 ` [PATCH12/17] pefile: Strip the wrapper off of the cert data block David Howells
2014-07-09 15:16 ` [PATCH13/17] pefile: Parse the presumed PKCS#7 content of the certificate blob David Howells
2014-07-09 15:16 ` [PATCH14/17] pefile: Parse the "Microsoft individual code signing" data blob David Howells
2014-07-09 15:17 ` [PATCH15/17] pefile: Handle pesign using the wrong OID David Howells
2014-07-09 15:17 ` [PATCH16/17] pefile: Digest the PE binary and compare to the PKCS#7 data David Howells
2014-07-09 15:17 ` [PATCH17/17] pefile: Validate PKCS#7 trust chain David Howells
2014-07-09 16:03 ` [PATCH 00/17] KEYS: PKCS#7 and PE file signature checking for kexec Borislav Petkov
2014-07-09 16:21   ` Vivek Goyal
2014-07-09 16:28   ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30205.1405024657@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=kexec@lists.infradead.org \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox