Comment # 31 on bug 1209006 from Michal Suchanek

(In reply to Joey Lee from comment #30)

> I agree that the upstream solution is complex, and I do not fully understood
> the Imputed or Transitive concept in their theory. But I think that those
> certificates in db/mok must be differentiated based on functionality
> purpose. The trust is not spread from a purpose to other purposes.

And the x509 has purpose flags but the kernel trashes all of them except the CA
flag. If it wants to differentiate purposes it needs to store those purpose
flags.

> 
> Using usage extension in certificates to separate different purposes is a
> strategy. IMA maintainer uses CA in BasicConstraints, digitalSignature and
> keyCertSign to identify CA MOK. And NIAP PPOS certification uses codeSign
> extend key usage. 

Which applies to both kexec and module loading, these are both code. Loaded
into the same security context even. Yet kernel upstream inexplicably insists
on using different keys for these making their scheme unusable for us.

If it wants to differentiate kexec and module loading, or modules by different
vendors it needs to invent new extension for that. Until such certificate
extension exists both kernel and modules are code.