I think that the best way forward is to ask SECDISPATCH. I do not think SUIT is a bad answer, but we have a process to pick.
Russ > On Jun 14, 2020, at 5:23 PM, Michael Richardson <[email protected]> wrote: > > Hi, I read draft-moran-suit-mud today. > It would naturally fall into a MUD WG if we had that. > As it is, I have no idea where to discuss this, and thus another shotgun. > I gather the mailman deletes my Reply-To suggestions. > > I feel that this document should be adopted and the details filed in, but I > have no idea what WG it belongs in given the current state of things. > {It totally fits into the IoT lifecycle security WG I had proposed} > > I knew it was around since it was talked about at the Hackathon a bunch, but > I hadn't read the result until today. > > If you use Hypothesis my comments are at: > > https://hyp.is/go?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-moran-suit-mud-00.html&group=__world__ > I'm not sure what that does if you don't have the plugin installed. > I'd prefer to write them as a pull request since they are mostly suggestions > on fixing some wording rather than any kind of substantive request for > changes. > > Substantive comments: > "At the time of onboarding, devices report their manifest in use to the MUD > manager." > > so I think that we will need to detail this!!! > When using an IDevID based onboarding system (BRSKI/BRSKI-TEEP/BRSKI-AE or > EAP-NOOB with some certificate based system) then the MUD certificate OID is > available. > But, that's not the manifest of the software currently running, and it would > not be reasonable to embed that into the IDevID for the reasons I explain at: > > https://datatracker.ietf.org/doc/html/draft-richardson-opsawg-mud-acceptable-urls-00#section-2 > > More interesting is that you are requesting: > Each time a device is updated, rebooted, or otherwise substantially > changed, it will execute an attestation. > Among other claims in the Entity Attestation Token (EAT) > [I-D.ietf-rats-eat], the device will report its software digest(s), > configuration digest(s), primary manifest URI, and primary manifest > digest to the MUD manager. > > Well, that attestation is actually ideal for use during onboarding as well. > > It seems to me that the path of trust should go like: > > 1) (Manufacturer IDevID PKI) -> IDevID. > 2) IDevID -> "generic" MUD file (signed by key from Manufacturer PKI <%>) > 3) MUD file -> identifies key that signs firmware manifests > 4) SUIT MANIFEST -> "specific" (per version) MUD file > > I had previous suggested that the SBOM be attached to the per-version MUD > file, but I am not so sure anymore. > > Note that the EAT described above would be *Evidence* (not Attestation > Results), per the architecture. It would be signed by the IDevID in <2>. > > Finally, if you didn't see my message to secdispatch about IDevID. > > https://mailarchive.ietf.org/arch/msg/secdispatch/Hqe1lHG2wnW_9NxJLazEYbmGYN0/ > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =-
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
