linux-kernel - Re: [PATCH06/17] PKCS#7: Verify internal certificate chain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <30205.1405024657@warthog.procyon.org.uk>
Date:	Thu, 10 Jul 2014 21:37:37 +0100
From:	David Howells <dhowells@...hat.com>
To:	Valdis.Kletnieks@...edu
Cc:	dhowells@...hat.com, keyrings@...ux-nfs.org,
	linux-security-module@...r.kernel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH06/17] PKCS#7: Verify internal certificate chain

Valdis.Kletnieks@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/