On Wed, Aug 14, 2019 at 2:44 PM Peter Jones <pjones@xxxxxxxxxx> wrote: > On Wed, Aug 14, 2019 at 08:35:57AM -0400, Paul Moore wrote: > > On Tue, Aug 13, 2019 at 2:03 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > On 8/12/19 8:35 AM, Josh Boyer wrote: > > > > On Mon, Aug 12, 2019 at 11:23 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: ... > > > May I ask why you want the cert? > > > > I'm working on extensions to tboot to support kernel signatures > > instead of hashes. Not wanting to reinvent the wheel I figured I > > would reuse the signed PECOFF format used by UEFI Secure Boot; the > > Fedora kernels are one of the kernels I've been using for testing. > > Why? Just throw tboot into the sea already. It's completely > incompatible with the concept of a real chain of trust for booting. I'm not using tboot/TXT for secure boot. > > FWIW, once I have something that is working properly and suitable for > > upstreaming (it is still a prototype) I plan to work on getting it > > merged into the tboot upstream. > > Is there a broader goal here? It would seem to be academically > interesting but fundamentally untrustable, because it's using tboot. This assumes I'm using tboot as a secure boot mechanism, I'm not. I don't have anything written up on the approach yet, but the abstract/teaser for the LSS-NA talk is below. https://lssna19.sched.com/event/RHaB/securing-tpm-secrets-with-txt-and-kernel-signatures-paul-moore-cisco > > However, regardless of my work on tboot, I think it would be nice to > > be able to verify a kernel signature without relying on the > > certificate chain stored within the kernel. > > You realize that's how literally all signature verification works, > right? Sigh. It sounds like you are missing some of the finer details in my comment Peter, as well as assuming I'm an idiot. Perhaps I wasn't clear enough in my comments, but what I was trying to get across was that I was using the certificates (signer and CA) that were part of the signed kernel image as way to verify the kernel signature without any external root/CA. Typically proper signature verification relies on a root of trust located *outside* the signed object being verified, for example UEFI Secure Boot relies on the roots/CAs stored in the firmware itself. Anyway, I extracted info I needed, it's sufficient from my purposes at the moment, you're off the hook. -- paul moore www.paul-moore.com _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
