> > * 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. 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. 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. :/ _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
