Re: EU-CRA and the ongoing standardization work

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]