On Thu, Jun 12, 2008 at 4:32 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > I will analyze this further, later. However, I see one minor issue with this > proposal right away: there is no way for a key to delegate some but not all > of its authority. Thus, at every level, separate keys must be used for > separate purposes - activation, kernel, ramdisk, and secure-reflash - or all > of these permissions will be synonymous. This is totally feasible; however, > this does limit the extensible usability of this format.
For better or worse, we already have separate keys for all these purposes. The current proposal continues with the 'one key per function' idea. > I suggest that the <serial number> part of the chained signed data be > replaced by an application-specific <application>:<authorization details> > field. For example, for activation, this could be > act01:<serial number> > 3 2 1 ? This is reasonable, but parsing an arbitrary-length field is tricky. We tried adding a 'disposition' field to the act01 and dev01 formats to future-proof it, but as you can see in the end we failed to anticipate the exact direction of expansion which would be needed. In the end, I'd prefer adding a new 'dev02' or 'act02' format if needed to provide application-specific features, rather than add a field to sig02 whose use is yet-unknown. Arguments to the contrary are requested. In actual fact, the delegations that would be useful for kernel/ramdisk/secure reflash would be over a (quite large, and daily changing) set of laptops. Ideas to address that are welcome, but I suspect they won't fall under the desired 'minimal modifcation to existing format' goals. --scott -- ( http://cscott.net/ ) _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
