[T2TRG] T2TRG interim meeting follow-ups - draft-irtf-t2trg-taxonomy-manufacturer-anchors-00

[Mohit Sethi <[e-mail]>]

During the last T2TRG interim meeting, I had promised to provide some 
comments on "draft-irtf-t2trg-taxonomy-manufacturer-anchors-00". The 
chairs sent a reminder so I decided to do a quick read-through of the 
entire draft to provide some initial comments.

Overall comments:

* I think the draft could benefit from help and guidance by people who 
are actually involved in manufacturing PCBAs and provisioning keys. I 
have worked with NXP processors where a fuse map containing public keys 
is created and shared with factory for programming/fusing on the factory 
line: 
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/112842/1/AN4581.pdf. 
NXP even supports firmware/software encryption and I know of one 
deployment where it is used. Similarly, I have had experience with 
Microchip provisioning of symmetric keys where the symmetric key is 
shared with the chip vendor. I am not sure which terminology from this 
draft will I use in such cases? I am certainly not an expert but I can't 
easily connect the terminology in the draft with my limited real-word 
experience.

* The draft fails to distinguish between measured boot and secured boot

* Is it advisable to reference a Wikipedia page in an IRTF draft: 
https://en.wikipedia.org/wiki/In-circuit_testing#Bed_of_nails_tester? As 
said, someone with experience can help with describing how functional 
testing (FCT) of PCBAs is done in practice: 
https://www.scanfil.com/newsroom/scanfil-odin.

* Generally, reading and writing to TPM requires some minimal OS? How is 
that signed/verified/booted?

* When manufacturing my IoT device, how is the primary stage bootloader 
signed and verified?

Other comments:

I don't understand the phrase "where identities are tied up in the 
provision of symmetric shared secrets".

What are "group identity keys"? From a quick scan, I did not find any 
reference to group keys in the FIDO tech note cited.

In general, I feel the draft is hard to parse for non-regular IETF 
participants. I would presume a RG document to be understandable by a 
wider audience.

There are lots of heavy words "provenance", "security artifacts", etc. 
It would be nice if some concise explanation for non-experts like me can 
be provided.

I did not understand how [RFC7168] serves as a humorous example? Does 
RFC7168 really allow a teapot to pretend to be a coffepot - thus serving 
as an example of "device may mislead audit systems"? On a quick scan, it 
doesn't seem to be the case?

I did not understand the phrase "which is built into the CPU package". 
What is a CPU package?

Thing-2-thing research group is about IoT devices. I don't understand 
how is it helpful to reference desktop operating systems and browsers. 
If I was an IoT device startup, what are the different options for 
building a secure read-only repository of trusted CAs?

Out of curiosity, are there some practical examples where CA private 
keys are protected with secret splitting? In the case of DNSSEC, is it 
really the private key that is split? Or is just that a bunch of keys 
(unrelated to the private key) are needed for opening the vaults.

The draft says "Consider the situation where a hurricane or earthquake 
takes out all power and communications at an organizations' primary 
location, and it becomes necessary to activate the backup site. What 
does it take to do that?" I think at least many medium-to-large 
organizations have detailed (and often tested) disaster recovery plans 
which are also needed for ISO 27001 certification.

--Mohit