lkml.org 
[lkml]   [2022]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 00/10] Add CA enforcement keyring restrictions
From
Date
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

\
 
 \ /
  Last update: 2022-12-18 13:24    [W:0.101 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site