On Fri, May 28, 2021 at 07:24:45AM +0200, Eliot Lear wrote:
> Hi Toerless,
>
> I think you may have overcomplicated things. If the device or manufacturer
> wants to provide the SBOM, the easisest thing would be to put a MUD URL into
> the cert that can be resolved, and then use .well-known/sbom, where you
> authenticate either the trust anchor provided in the voucher or subsequent
> trust anchors provided by EST to the pledge. Absent that authentication you
> can just return a 400.
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. I can only venture to guess your work flow would only
allow to retrieve SBOM information after the pledge has already received a
certificate. The whole point is to not give a pledge a "you're fully trusted"
cert if it can not be fully trusted because of its SBOM.
Cheers
Toerless
> Eliot
>
> On 28.05.21 01:38, Toerless Eckert wrote:
> > One hought that cam up when reading subject draft:
> >
> > SBOM is likely something many devices may want to keep confidential.
> > But SBOM may also be highly beneficial for attestation during bootstrap.
> >
> > In BRSKI (RFC8995), we have a boostrap TLS connection for which the client
> > device
> > receives a very strong authentication (from its own manufacturer via a
> > voucher),
> > that the other end of the connection should be consiered to be the owner of
> > the
> > device - and hence could be sosidered to be a valid receiver of the SBOM,
> > if anyone is.
> >
> > 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.
> >
> > Long story short: I think it would be great if this SBOM draft would support
> > BRSKI in so far as:
> >
> > -> If device supporting this SBOM standard also supports BRSKI, and
> > it wants to support attestation for BRSKI enrollment, then the device
> > will offer to provide it's SBOM to the BRSKI registrar after
> > successfully
> > completing authentication of the provisional BRSKI TLS connection.
> >
> > -> offering to provide it's SBOM could be done by a GET to a new
> > well-known URI, something like /.well-known/brski/sbom-offer
> > and some well-defined response format providing e.g.: the actual URI
> > to send the SBOM to, followed by a POST to that URI
> >
> > This would allow BRSKI to take SBOM into consideration whether or not to
> > provide a certificate to the client device in the next BRSKI stps,
> > or (in more intelligent environments), make the registrar provide a
> > different certificate than a normal operational one, when the
> > device can not yet be full trusted, but some additional remote software
> > upgrades or the like could make that happen.
> >
> > There is actually very little i see fitting as extensions to BRSKI before
> > enrolling the client with a cert, but SBOM would pretty much be on the
> > top of that list. HWBOM would of course be nice too, but most often the
> > significant aspects of that are deducible from the X520SerialNumber for
> > good vendors.
> >
> > Cheers
> > Toerless
> >
> > In-Reply-To: <983c17c3-1c0b-9626-4009-bb442ad28...@lear.ch>
> >
> > On Tue, May 25, 2021 at 03:01:14PM +0200, Eliot Lear wrote:
> > > Hi,
> > >
> > > For those of you who don???t know, Common Security Advisory Format (CSAF)
> > > is
> > > an evolution on Common Vulnerability Reporting Framework. Such an object
> > > could easily be delivered with an SBOM. It has a slightly different
> > > characteristic in terms of update frequency. CSAF changes may happen
> > > independently of software updates, and generally would*not* be hosted on
> > > individual devices (at least, I don???t see the use case).
> > >
> > > CSAF files indicate what products and versions are vulnerable (and what
> > > are
> > > not), and what if any remediations are available, not unlike a classic
> > > PSIRT
> > > advisory.
> > >
> > > My proposal is to add into the draft an optional URL that indicates the
> > > CSAF
> > > object for This device, a???la:
> > >
> > > > container sbom {
> > > > ???
> > > > leaf csaf-location {
> > > > type inet:uri;
> > > > description ???Location of CSAF file???;
> > > > }
> > > I would add some descriptive text similar to the above in as well.
> > >
> > > Does this raise any concerns?
> > >
> > > Eliot
> >
> >
> >
> > > _______________________________________________
> > > OPSAWG mailing list
> > > OPSAWG@ietf.org
> > > https://www.ietf.org/mailman/listinfo/opsawg
> >
>
--
---
t...@cs.fau.de
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
