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
