Re: [PATCH v4 00/12] Enroll kernel keys thru MOK

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

 




On 8/25/21 6:27 PM, James Bottomley wrote:
On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote:
On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote:
Jarkko, I think the emphasis should not be on "machine" from
Machine Owner Key (MOK), but on "owner".  Whereas Nayna is
focusing more on the "_ca" aspect of the name.   Perhaps
consider naming it "system_owner_ca" or something along those
lines.
What do you gain such overly long identifier? Makes no sense.
What is "ca aspect of the name" anyway?
As I mentioned previously, the main usage of this new keyring is
that it should contain only CA keys which can be later used to
vouch for user keys loaded onto secondary or IMA keyring at
runtime. Having ca in the  name like .xxxx_ca, would make the
keyring name self-describing. Since you preferred .system, we can
call it .system_ca.
Sounds good to me.  Jarkko?

thanks,

Mimi
I just wonder what you exactly gain with "_ca"?
Remember, a CA cert is a self signed cert with the CA:TRUE basic
constraint.  Pretty much no secure boot key satisfies this (secure boot
chose deliberately NOT to use CA certificates, so they're all some type
of intermediate or leaf), so the design seems to be only to pick out
the CA certificates you put in the MOK keyring.  Adding the _ca suffix
may deflect some of the "why aren't all my MOK certificates in the
keyring" emails ...


My understanding is the .system_ca keyring should not be restricted only to self-signed CAs (Root CA). Any cert that can qualify as Root or Intermediate CA with Basic Constraints CA:TRUE should be allowed. In fact, the intermediate CA certificates closest to the leaf nodes would be best.

Thanks for bringing up that adding the _ca suffix may deflect some of the "why aren't all my MOK certificates in the keyring" emails.

Thanks & Regards,

    - Nayna




[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