Re: Reverted changes on https://wiki.debian.org/SecureBoot
Hi!
On Tue, Aug 16, 2022 at 01:42:54PM +0800, Chew, Kean Ho wrote:
>Hi Steve,
>
> 1. No worries. Thank you for reviewing my changes as well. This is my first
> honest to goodness contribution to the Debian community and I was worried
> yesterday when the changes went live immediately.
Fair enough! :-)
> 2. Quick question: about the x509 chain of trust investigation I
> added, do you know where I should upstream the knowledge for
> those who want to spin a SB CA and cert from their existing chain
> (e.g. company private CA --> spin MOK CA --> spin MOK key +
> cert?
To be honest, this *does* sound like a useful set of knowledge to
share. I did a revert which killed both of your changes, of
course. Maybe add a new page (SecureBoot/CA maybe?) and start adding
things there?
> 1. This knowledge is suitable for those who maintain multiple
> different fleets of SB computing hardware where a MOK CA cert
> is a lot easier to maintain compared to generating root CA
> for each machine as guided in wiki.
Yup.
> 2. Given the fact that wiki caters for all levels of users, x509
> itself and its maintenance is already complicated to do it
> securely, I really do not want to complicate Debian user
> experience. In the worst case scenario, I can write a
> technical paper and upload to Zenodo to preserve the
> knowledge if that's needed. Please advise.
That might be a reasonable option too, of course! Sharing stuff via
the Debian wiki is typically *my* preferred route, but I've also
written a lump of stuff in the upstream shim wiki too:
https://github.com/rhboot/shim/wiki
That might even be a better place, possibly.
> 3. List of data I tested:
> 1. ED25519 x509 implementation investigation - verdict: ED25519 is not
> supported.
> 2. The issuer-subject must be SHAX-RSA2048 matter (is this a bug?) -
> verdict: Stick to using RSA2048. SHA256 and SHA512 hashers were
> tested working.
> 3. The steps to chain ED25519 upstream into RSA2048 MOK CA
> 4. The minimal x509 configurations for MOK CA and MOK cert
Right. The exact configurations that are supported are probably better
found in the shim source, I think. I believe that most people are
using RSA-2048, and I'm aware of issues that some people have found in
firmware if they try to use 4096-bit keys instead. To a certain extent
I think we're limited to what's been supported for years in EDK2 and
the various vendor firmware releases.
> 3. As for the upgrade instructions part, understood and duly noted. Will
> cross-check the shim-signed and grub-efi-amd64-signed deb packages with the
> data here later. I was coming from the debootstrap minimal-base path
> complying to https://wiki.debian.org/DontBreakDebian.
Aha! That path will be slightly different to the d-i path that's most
common, and I see you've filed a bug too. More over there.
> 4. Also, the strict "--bootloader-id=debian" condition where if it is changed
> to something else, the shimx64.efi failed to locate /boot/grub.cfg. Is this
> behavior a bug or expected limitation from signed shim?
You might have tripped over grub_prefix not being set appropriately.
Can you describe *exactly* what setup you've tried, please? There's a
lot of scope for a setup mismatch here...
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Dance like no one's watching. Encrypt like everyone is.
- @torproject
Reply to: