Re: [PATCH v3 00/10] Add CA enforcement keyring restrictions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


--
Best regards,
Coiby




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux