Hi Julius,
Am 12.12.25 um 02:57 schrieb Julius Werner:
* What's the last point at which we can bring up discussions about
significant changes (e.g. adding/dropping requirements)?
That point (for firmware, i.e. "boot managers" in CRA-speak) was last
week if you wanted the easy route. Sorry.
That... is very bad news, although I appreciate your candor. It would
have been great if these deadlines had been communicated more clearly
in advance.
To people familiar with the usual standards processes, the pace at which
the CRA standards have been progressing would best be described as
"ludicrous breakneck speed".
The deadlines are extremely tight and I haven't ever seen another
standards process moving even close to that speed. Think "instant code
review on IRC" speed back in the time when that was a thing.
I did try to warn people on this mailing list about this in a reply to
the 2025-08-06 meeting minutes:
> The timeline for that standards process is extremely tight and a
participation later this year might already be pointless.
Admittedly, starting a new thread would probably have been more visible.
My apologies for that.
Back then, we didn't know the exact first cutoff date yet, and I
expected that cutoff date to be sooner than it actually happened. The
deadlines back then were extended a bit, but not by much.
The good news is that participation is still effective and useful.
The current draft seems to be designed to very tightly follow certain
UEFI Secure Boot concepts rather than define broader security goals
that an implementation can meet as it sees fit. For example,
RQ-INTEGRITY-016 says "The boot manager shall support hierarchical
trust with root and intermediate certificates." — what's the point of
that for platforms where the entire boot manager with all components
is signed by a single entity? And RQ-INTEGRITY-017 demands "The boot
manager shall support transition between certificate authorities
during ownership changes." — does that mean that all boot managers
need to use (x509?) certificates for their trust anchor and support
ownership changes (that term isn't actually defined anywhere else in
the document)? Or is it just a requirement for platforms that do? No
Android phone and no Chromebook today supports "ownership changes"
(unless that just means physically unprotecting the flash and flashing
a different key, but it sounds like they're talking about some fancy
online key exchange mechanism here?), and it's not really feasible
(and definitely not helpful to users) to redesign all their
verification mechanisms from scratch just to include this capability.
Those mechanisms don't make users more secure, they're just feature
creep that adds complexity and therefore risk. RQ-INTEGRITY-058 says
"The boot manager shall verify components using at least two distinct
verification mechanisms (e.g. hash-based and signature-based
verification)." which... doesn't make sense at all? Verifying
something with public key crypto generally always requires *both* a
signature and a hash (although you can also build secure systems with
purely shared secret HMAC-based verification instead, which can also
be a valid approach for certain device types that many of the
requirements here don't acknowledge at all FWIW...), but those aren't
"distinct mechanisms", those are two necessary steps of the same
single mechanism neither of which can really stand on its own.
I can't answer these questions right now because I didn't read the very
latest boot manager draft yet (we have a considerable number of
standards under review). I will try to address your questions next week
unless someone else beats me to it.
That said, if you can rephrase those questions as comments and provide
proposals for alternative wording or fixed content, you have a very good
chance to adjust this.
It seems that a lot of things in the details (not just the formatting)
have also changed with the last revision a few weeks ago (e.g. there
was a ton of duplication between AUTH-BASE and INTEGRITY-BASE that
seems to have now been mostly cleaned up). The window between "this is
actually the finished draft worth looking at" and "it's basically
already to late to make real changes" was really not long enough to be
workable for a document of this size here. :/
While this may be no consolation, some of the other standards are even
bigger and move even faster. Just following one of them requires 10+
hours per week plus the time needed to comment.
I'm active in the CRA standards process (three days of full-day presence
meetings this week alone) and know the rules. If you need help shaping
the comments and questions into the desired form, I'm willing to help.
Let me share some good news: I talked with the rapporteur for boot
managers a few hours ago (after all, we were in the same meeting room
for three days) and he is still very much interested in comments,
preferably against the latest version of the draft. It will be
challenging for him to squeeze in those comments, but better try now
than later.
Regards,
Carl-Daniel
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
