Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <30ee58d0b48ce96b4c9a334019c4b8ae8394bef0.camel@linux.ibm.com>
Subject: Re: [PATCH 3/4] KEYS: CA link restriction
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>
Date:   Wed, 09 Mar 2022 12:33:50 -0500
In-Reply-To: <068F32E0-B202-4B20-9DE7-57373EF71BFE@oracle.com>
References: <20220301173651.3435350-1-eric.snowberg@oracle.com>
         <20220301173651.3435350-4-eric.snowberg@oracle.com>
         <47f3654e-892d-a35a-e77c-70ada1ebcf43@linux.ibm.com>
         <2415444C-AD8F-4F03-8B1C-C0770F83ADAE@oracle.com>
         <e2dd58cd6074ae692256333b43b5ecde70bcdbdd.camel@linux.ibm.com>
         <67456A73-8B72-4DB6-8E23-7C603661A0A4@oracle.com>
         <22860730-d615-5683-6af0-05b6f4f3e71d@linux.ibm.com>
         <e10f2161aaa69a9d301b3a16a37cbab266318aee.camel@linux.ibm.com>
         <068F32E0-B202-4B20-9DE7-57373EF71BFE@oracle.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Precedence: bulk

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