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