linux-kernel - Re: [PATCH 3/4] KEYS: CA link restriction

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <30ee58d0b48ce96b4c9a334019c4b8ae8394bef0.camel@linux.ibm.com>
Date:   Wed, 09 Mar 2022 12:33:50 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>,
        Stefan Berger <stefanb@...ux.ibm.com>
Cc:     Jarkko Sakkinen <jarkko@...nel.org>,
        David Howells <dhowells@...hat.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "nayna@...ux.ibm.com" <nayna@...ux.ibm.com>,
        "mic@...ux.microsoft.com" <mic@...ux.microsoft.com>,
        Konrad Wilk <konrad.wilk@...cle.com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 3/4] KEYS: CA link restriction

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

> > On Mar 8, 2022, at 5:45 AM, Mimi Zohar <zohar@...ux.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