linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.com>,
	Stefan Berger <stefanb@linux.ibm.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	David Howells <dhowells@redhat.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"serge@hallyn.com" <serge@hallyn.com>,
	"nayna@linux.ibm.com" <nayna@linux.ibm.com>,
	"mic@linux.microsoft.com" <mic@linux.microsoft.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 3/4] KEYS: CA link restriction
Date: Wed, 09 Mar 2022 12:33:50 -0500	[thread overview]
Message-ID: <30ee58d0b48ce96b4c9a334019c4b8ae8394bef0.camel@linux.ibm.com> (raw)
In-Reply-To: <068F32E0-B202-4B20-9DE7-57373EF71BFE@oracle.com>

On Tue, 2022-03-08 at 18:02 +0000, Eric Snowberg wrote:

> > On Mar 8, 2022, at 5:45 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:

> > Agreed, as long as the other two criteria are also met: CA and keyUsage
> > should be required and limited to keyCertSign.
> 
> I have added the key_is_ca in the public_key header.  I can look at adding the usage
> too. Before doing this I would like to understand the "limited to" above.  Many CA keys 
> that have keyCertSign set, also have digitalSignature set for key usage.  For 
> example:
> 
> http://cacerts.digicert.com/DigiCertEVCodeSigningCA-SHA2.crt
> 
> Are you saying we would want to exclude a CA like the one above, since it as the 
> digitalSignature usage set too?  

Yes, the "machine" keyring is defining a new root of trust to support
allowing end-users the ability "to add their own keys and sign modules
they trust".  There should be a clear distinction between  keys used
for certificate signing from those used for code signing.  Certificate
signing keys should be added to the .machine keyring.  Code signing
keys should be added to the IMA keyring.

thanks,

Mimi


  parent reply	other threads:[~2022-03-09 17:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 17:36 [PATCH 0/4] Add CA enforcement in the machine keyring Eric Snowberg
2022-03-01 17:36 ` [PATCH 1/4] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2022-03-01 17:36 ` [PATCH 2/4] X.509: Parse Basic Constraints for CA Eric Snowberg
2022-03-04 15:10   ` Stefan Berger
2022-03-07 18:02     ` Eric Snowberg
2022-03-01 17:36 ` [PATCH 3/4] KEYS: CA link restriction Eric Snowberg
2022-03-04 15:28   ` Stefan Berger
2022-03-07 18:06     ` Eric Snowberg
2022-03-07 23:01       ` Mimi Zohar
2022-03-07 23:38         ` Eric Snowberg
2022-03-08  2:31           ` Stefan Berger
2022-03-08 12:45             ` Mimi Zohar
2022-03-08 13:56               ` Stefan Berger
2022-03-08 18:02               ` Eric Snowberg
2022-03-09 17:12                 ` Stefan Berger
2022-03-09 17:17                   ` Stefan Berger
2022-03-09 18:13                   ` Eric Snowberg
2022-03-09 19:02                     ` Stefan Berger
2022-03-11 18:44                       ` Eric Snowberg
2022-03-11 20:23                         ` Stefan Berger
2022-03-14 12:00                           ` Stefan Berger
2022-03-09 17:33                 ` Mimi Zohar [this message]
2022-03-01 17:36 ` [PATCH 4/4] integrity: CA enforcement in machine keyring Eric Snowberg
2022-03-04 23:19   ` Stefan Berger
2022-03-07 18:13     ` Eric Snowberg
2022-03-07 18:36       ` Stefan Berger
2022-03-07 18:48         ` Eric Snowberg
2022-03-06 23:33 ` [PATCH 0/4] Add CA enforcement in the " Mimi Zohar
2022-03-07 18:55   ` Eric Snowberg
2022-03-09 18:43 ` Mimi Zohar

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=30ee58d0b48ce96b4c9a334019c4b8ae8394bef0.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.snowberg@oracle.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@linux.microsoft.com \
    --cc=nayna@linux.ibm.com \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).