Toerless Eckert <t...@cs.fau.de> 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.
> 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 think that SBOM fits best as an attestation attribute, and not the other way
around.
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.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
