Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2d75dfd105f8558ecd1074d64e4252ddd63b698b.camel@linux.ibm.com>
Subject: Re: [PATCH v3 00/10] Add CA enforcement keyring restrictions
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Coiby Xu <coxu@redhat.com>,
        Eric Snowberg <eric.snowberg@oracle.com>
Cc:     Jarkko Sakkinen <jarkko@kernel.org>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
        "paul@paul-moore.com" <paul@paul-moore.com>,
        "jmorris@namei.org" <jmorris@namei.org>,
        "serge@hallyn.com" <serge@hallyn.com>,
        "pvorel@suse.cz" <pvorel@suse.cz>,
        "noodles@fb.com" <noodles@fb.com>, "tiwai@suse.de" <tiwai@suse.de>,
        Kanth Ghatraju <kanth.ghatraju@oracle.com>,
        Konrad Wilk <konrad.wilk@oracle.com>,
        Elaine Palmer <erpalmer@linux.vnet.ibm.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-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>
In-Reply-To: <20221216140648.h32gn5qf3igorpzi@Rk>
References: <20221214003401.4086781-1-eric.snowberg@oracle.com>
         <b8e54d077da633132eb6da03ea536face095a425.camel@linux.ibm.com>
         <4CE6F17D-9D87-4024-9E1A-FDFE7C29D5FC@oracle.com>
         <1c51910a35a1d113256494827fd66ccc7473632e.camel@linux.ibm.com>
         <17855993-519C-4DAC-B62F-9DB473CF249B@oracle.com>
         <7df94da37c100c160436892a6996ba30e3fd6dc8.camel@linux.ibm.com>
         <21E52C3E-0778-4908-AF44-F65D57BEC4E0@oracle.com>
         <20221216140648.h32gn5qf3igorpzi@Rk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Date:   Sun, 18 Dec 2022 07:21:33 -0500
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Fri, 2022-12-16 at 22:06 +0800, Coiby Xu wrote:
> Hi Eric and Mimi,
> 
> On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote:
> >
> >
> >>>>>>> A CA cert shall be defined as any X509 certificate that contains the
> >>>>>>> keyCertSign key usage and has the CA bit set to true.
> >>>>>>
> >>>>>> Hi Eric,
> >>>>>>
> >>>>>> Allowing CA certificates with the digitalSignature key usage flag
> >>>>>> enabled defeats the purpose of the new Kconfig.  Please update the
> >>>>>> above definition to exclude the digitalSignature key usage flag and
> >>>>>> modify the code accordingly.
> >>>>>
> >>>>> Within v2, the request was made to allow Intermediate CA certificates to be
> >>>>> loaded directly.  The Intermediate CA referenced was the one used by kernel.org.
> >>>>> This Intermediate CA contains both digitalSignature and keyCertSign.  If the code
> >>>>> is changed to exclude this certificate, now the root CA has to be loaded again.  Is that
> >>>>> the intent?
> >>>>
> >>>> That definitely was not the intent.  Nor would it address the issue of
> >>>> a particular intermediate CA certificate having both keyCertSign and
> >>>> digitalSignature.
> >>>
> >>> Sorry, I’m not following.  Why is it an issue that an intermediate CA certificate contains
> >>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate
> >>> CA cert like the one used on kernel.org?
> >>
> >> I must be missing something.  Isn't the purpose of "keyUsage" to
> >> minimize how a certificate may be used?   Why would we want the same
> >> certificate to be used for both certificate signing and code signing?
> >
> >Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set.
> >Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature
> >set.  Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be
> >challenging and will severely limit usage.
> 
> How about allowing both keyCertSign and digitalSignature asserted but
> issuing a warning for this case?
> 
> Here's my rationale for this proposal.
> 
> I assume we should conform to some X.509 specifications. So I checked
> "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and
> Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10)
> [2].
> 
> [1] states in 4.2.1.3. Key Usage,
>     "If the keyUsage extension is present, then the subject public key
>     MUST NOT be used to verify signatures on certificates or CRLs unless
>     the corresponding keyCertSign or cRLSign bit is set.  If the subject
>     public key is only to be used for verifying signatures on
>     certificates and/or CRLs, then the digitalSignature and
>     nonRepudiation bits SHOULD NOT be set.  However, the digitalSignature
>     and/or nonRepudiation bits MAY be set in addition to the keyCertSign
>     and/or cRLSign bits if the subject public key is to be used to verify
>     signatures on certificates and/or CRLs as well as other objects."
> 
> and [2] states in 8.2.2.3 Key usage extension that,
>    "More than one bit may be set in an instance of the keyUsage extension.
>    The setting of multiple bits shall not change the meaning of each
>    individual bit but shall indicate that the certificate may be used for
>    all of the purposes indicated by the set bits. There may be risks
>    incurred when setting multiple bits. A review of those risks is
>    documented in Annex I."
> 
> I interpret the above texts as we should allow both keyCertSign and
> digitalSignature. However [2] warns about the risks of setting multiple
> bits. Quoting Annex I,
> 
>    "Combining the contentCommitment bit in the keyUsage certificate
>    extension with other keyUsage bits may have security implications
>    depending on the security environment in which the certificate is to be
>    used. If the subject's environment can be fully controlled and trusted,
>    then there are no specific security implications. For example, in cases
>    where the subject is fully confident about exactly which data is signed
>    or cases where the subject is fully confident about the security
>    characteristics of the authentication protocol being used. If the
>    subject's environment is not fully controlled or not fully trusted, then
>    unintentional signing of commitments is possible. Examples include the
>    use of badly formed authentication exchanges and the use of a rogue
>    software component. If untrusted environments are used by a subject,
>    these security implications can be limited through use of the following
>    measures:   
>     – to not combine the contentCommitment key usage setting in
>       certificates with any other key usage setting and to use the
>       corresponding private key only with this certificate;   
>       
>     – to limit the use of private keys associated with certificates that
>       have the contentCommitment key usage bit set, to environments which
>       are considered adequately controlled and trustworthy"
> 
> So maybe it's useful to add a warning if both keyCertSign and
> digitalSignature are asserted.

Coiby, thank you for adding these details.  I was hoping others would
chime in as well.  I agree at minimum there should be a warning.

Perhaps instead of making INTEGRITY_CA_MACHINE_KEYRING dependent on
INTEGRITY_MACHINE_KEYRING, make them a Kconfig "choice" to support the
more restrictive certificate use case requirements:  all certificates,
CA certificate signing and digital signature, only CA certificate
signing.

-- 
thanks,

Mimi