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: <[email protected]>
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
