Toerless,Ultimately this is an authorization problem. How you do that is entirely up to you. I have given you a few examples. I don't see how an additional endpoint to retrieve the same object would change that.
Eliot On 28.05.21 19:49, Toerless Eckert wrote:
On Fri, May 28, 2021 at 06:59:53PM +0200, Eliot Lear wrote:On 28.05.21 17:31, Toerless Eckert wrote:On Fri, May 28, 2021 at 07:24:45AM +0200, Eliot Lear wrote: Explain to me how this work flow would allow for the registrar to decide whether to and/or what certificate to give to the pledge via EST based on SBOM information.Well, in that case, if the registrar has the iDevID of the pledge, it can retrieve the MUD file, which points to an SBOM.Except that we of course will also want to support many deployment cases where there may be an airgap during enrolment. And if the primary interest of a workflow is SBOM/attestation, then the manufacturer may not want to engage in the cost of MUD cloud service. Aka: i like o keep solutions modular so we're not forcing manufacturers to have to invest into more system components than necessary/beneficial for their customers use-cases.My guess is that such an SBOM would have to live off device, because there is no trust yet between pledge and registrar.Right.And so if trust is required to retrieve the SBOM, then it has to be between the registrar and the manufacturer.Which in addition to the above problems also includes the problem that tracking of firmware load is even more work, especially when there can be reseller firmware upgrades/customization or the like.This having been said, I think you may be applying the right policy at the wrong time. It may make more sense to first establish trust, but limit access to the device until you have the SBOM.That again also requires an additional layer of in-system complexity. So far, we have designed systems nicely with domain security indicated by their certificate. Now you need to add a whole new layer of per-device in-system security differentiation. I have seen how difficult those solutions become in enterprise 802.1 solutions. Additional VLANs, lots of radius server complexity of parameters to be pushed, etc. pp.that way, because at any time the posture of a device can be found to be wanting.Parsing failed. rephrase pls. In any case, to me, the local retrievel of SBOM information during BRSKI enrolment time seems to be very simple, very trustworthy by both sides, very simple to implement, very much in line with the purpose of BRSKI and with the least amount of system overhead. Aka: To me it would be the lowest hanging fruit option to bring in attestation by BOM. Cheers ToerlessEliot
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
