Talk:Partial key autonomy
We could avoid much of the pain of testing new firmware releases by putting the per-country keys in the mfg data sector. To start the process, we could issue a signed country-specific firmware release that would automatically install those keys in the mfg data sector. Subsequent firmware releases would be country-neutral, using the country-specific keys, since normal firmware updates preserve the mfg data sector untouched.
This would reduce the maintenance effort to a one-time-per-country event.
We might need to let the country to choose whether the country-specific system will accept both the country key and the global OLPC key, or just the country key. The former seems like a better idea to me, but I can imagine that some country might want the latter. It could be done by adding a tag to mark the country keys as "exclusive" or "alternative". (Mitch)
- Is adequate space available for the keys? --Michael Stone 20:15, 25 December 2008 (UTC)
Yes, plenty (Mitch)
Proposal 2 Discussion
Michael Stone speaking:
I don't understand Scott's proposal; hence, I'm going to try to write it up more clearly. I expect that Scott will read and correct my interpretation before we ship this software so that explanations are available to those who prefer paragraphs as well as those who prefer compressed fragments. Here we go:
- The best way to provide partial key autonomy is by means of a "policy overlay" stored in the mfg-data.
- This way, OLPC can supply a single firmware to all its customers but the firmware can still exhibit deployment-specific behavior in the presence of deployment-specific mfg-data.
- Using a policy overlay also allows the firmware to implement different policies for different locks, e.g. to augment the keyring for the DEVELOP lock while replacing the keyring for the FS lock.