my take from b/69321364:

distilling random points from the design doc:
- the normal root key used on CrOS systems is part of the AP RO firmware, hence we typically consider our root of trust to start there.  in reality, the root of trust is the EC RO firmware with newer devices, we've just never signed any of them before, so it's not a big deal.
- the EC RW firmware to do USB PD negotiation is loaded by the EC RO firmware and before anything AP related.  so making it a derivative of the root key doesn't really gain us anything since the root key wouldn't be used to verify the key.
- the EC in existing designs don't have any location to do rollback protection.
- there's no subkeys or any other verification chain here.  there is a single key, independent of anything else, burned into the EC RO by the signer, and used to fully verify the EC RW firmware.
- the EC, at least on the Chromeboxes we're looking at here, doesn't have control over the keyboard or other input signals.

talking to dnojiri@ today, he mentioned that the EC RW firmware is the same across all fizz models.  so all things considered, i don't think we need to pursue generation of sep keys here.

i might reconsider that position if:
- the EC could easily subvert the AP such that it'd be able to inject its own keys at runtime over the ones rooted in the AP firmware (e.g. through memory modification/mapping hacks)
- the EC RW image diverges and we end up shipping diff versions for different fizz models.

So, I took a look at  the doc, reviewed older comments that we had left, and concluded this plan is reasonable, including Mike's observations about keys. Will mark this as fixed.