On Fri, May 28, 2021 at 08:04:18PM +0200, Eliot Lear wrote:
> 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.
I don't think you have described any workflow that would allow to
achive what i claim is highly beneficial workflow: BRSKI decision to decide on
whether/what
certificate to assign based on SBOM information without introducing a lot
of additional complexity (cloud service) and likely impossible dynamic
update of such cloud based SBOM information.
Cheers
Toerless
>
> 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
> > Toerless
> >
> > > Eliot
>
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
