|
From: Mimi Z. <zo...@li...> - 2015-03-23 22:47:58
|
On Mon, 2015-03-23 at 16:43 +0200, Petko Manolov wrote: > On 15-03-23 07:00:13, Mimi Zohar wrote: > > Actually the diagram is a bit different than the one you showed. It > > would be: > > local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1)) > > | > > |---> IMA_key_2 (signed certificate (eg. selfsigned/CA 2)) > > I've gotten the above to work. The question is, does this make sense: > > local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1)) > | > |---> local-CA2 (on the .system keyring) ---> IMA_key_3 (signed cert/CA3) > > Here local-CA2 (that belongs to trusted entity) is used to sign > IMA_key_3 (and possibly others) which on turn IMA signs immutable > files. Assuming you trust all the keys on the system keyring, then any key on the system keyring can verify the certificate. Otherwise, use the "ca_keys=" boot command line option to specify the specific key. Mimi > > Right, once a key is signed by the local-CA and the local-CA key is > on the system keyring, use evmctl to load the key onto the .ima > keyring. > > Right. Can the .ima keyring handle CAs or just keys? If it can't then > i assume the only option is to get all CAs into the .system keyring > and use .ima for keys only. > > thanks, > Petko |