On Fri, May 28, 2021 at 10:23:21AM -0400, Michael Richardson wrote: > > Toerless Eckert <[email protected]> wrote: > > SBOM is likely something many devices may want to keep confidential. > > I think that national security will eventually trump (might be a > pun, not sure), emotional insecurities of manufacturers who made poor choices.
Can not quite parse this. Rephrase pls. I was just thinking about known exploits for specific software versions as the reason for not making the SBOM available to anyone who asks. I ran into that problem i think more than a decade ago when customers asked to not have software version be included in LLDP information freely available to anyone on the same LAN. Such as the virus infested employee PC whereas that virus would hen easily find attackable network equipment. Not much different when there is a well-known URL that such attacking systems could probe. > > In BRSKI (RFC8995), we have a boostrap TLS connection for which the > > client device receives a very strong authentication (from its own > > > On the other hand, BRSKI currently has no way to perform attestation of > > the device itself to decide whether or not it should trust it. > > Yes. > So, an open work item on BRSKI is to fit remote attestation into the flow. > What is requires is some choices around proof of freshness. > (See > > https://www.ietf.org/archive/id/draft-ietf-rats-architecture-12.html#name-appendix-a-time-considerati > > ) I guess the SBOM draft authors should chime in to explain if/how the SBOM information delivered would indicate if/how fresh the information is. > I think that SBOM fits best as an attestation attribute, and not the other > way around. If you have a larger attestation framework, sure. But if a more generic attestation framework might take a lot longer to complete, it would be nice to not have to stall solutions for SBOM if they can be had faster. Likewise, i would think that most uses of SBOM outside of BRSKI would be for attestation, and i don't think we would want to stop progressing SBOM information there with the argument that we first need an attestation framework. Or do we ? (i have no strong opinions other than just having been through a not so pleasent head-of-line blocking exercise for 7 years ;-)) > We also already know how to integrate MUD with BRSKI, and this connects MUD > with SBOM, so really, I don't think we need more. So tell me, how do you think a registrar would be able to include SBOM information in its decision whether to, or what certificate to give to a pledge during the EST enrollment. I don't see a solution for that without a solution like he one i proposed. I may of course be missing something. Cheers Toerless > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > -- --- [email protected] _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
