On Fri, 2022-12-23 at 16:13 +0000, Eric Snowberg wrote: > > > On Dec 22, 2022, at 8:41 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > On Thu, 2022-12-22 at 15:15 +0000, Eric Snowberg wrote: > >> > >>> On Dec 21, 2022, at 12:01 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > >>> > >>> On Wed, 2022-12-21 at 18:27 +0000, Eric Snowberg wrote: > >>>> > >>>>> On Dec 18, 2022, at 5:21 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > >>>>> > >>>>> 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. > >>>> > >>>> A warning could be added. > >>>> > >>>>> 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. > >>>> > >>>> As could support for additional restrictions. > >>>> > >>>> Would these additions be required within this series? What is missing from this > >>>> discussion is why would these additions be necessary? Why should the kernel > >>>> enforce a restriction that is beyond the scope of the X.509 spec? If a warning was > >>>> to be added, what would be the justification for adding this additional code? From > >>>> my research every single 3rd party code signing intermediate CA would be flagged > >>>> with the warning. Isn’t this just going to cause confusion? Or is there a benefit that > >>>> I am missing that needs to be stated? > >>> > >>> You're focusing on third party kernel modules and forgetting about the > >>> simple use case of allowing an end user (or business) to sign their own > >>> code. True they could use the less restrictive CA certificates, but it > >>> is unnecessary. > >> > >> My focus is on signing user-space applications, as outlined in the cover letter. This > >> series has nothing to do with kernel modules. Most end-users and businesses rely on > >> a third party to deal with code signing. All third party code signing services I have > >> found use an intermediate CA containing more than just the keyCertSign usage set. > >> It seems to be an industry accepted practice that does not violate the spec. Before writing > >> new code to either warn or exclude a third party intermediate CA, I would like to understand > >> the motivation behind this request. > > > > In older discussions there are comments like, "Any CA certificate, no > > matter if it's a root or an intermediate, must have the keyCertSign > > extension. If you want to sign a revocation list (CRL) with the CA > > certificate as well (you usually do want that), than you have to add > > cRLSign as well. Any other keyUsages can and should be avoided for CA > > certificates." > > > > The question as to "why" this changed to include "digitalSignature" was > > posed here [2] with the response being for "OCSP". It also includes a > > link to Entrusts root and intermediate CAs with just keyCertSign and > > cRLSign keyUsages. > > > > The matchine keyring is a means of establishing a new root of trust. > > The motivation for further restricting CA certificates to just > > keyCertSign and cRLSign keyUsages is to limit how the CA certificates > > may be used. They should not be used for code signing. > > Fair enough. If this will be viewed as justification for adding the additional > code, I can work on adding it. Above you mentioned a warning would be needed > at a minimum and a restriction could be placed behind a Kconfig. How about for > the default case I add the warning and when compiling with > INTEGRITY_CA_MACHINE_KEYRING the restriction will be enforced. Sounds good to me. To avoid misunderstandings, will there be a Kconfig menu with 3 options? There were a couple of other comments having to do with variable names. Will you address them as well? -- thanks, Mimi
