[Rats] CoSWID, was Re: Reviewing EAT for enterprise/cloud use cases

Hi Kathleen,

I was assuming CoSWIDs (or SWIDs) to become claims anyway, this wasn’t what I was asking. My question was whether SWIDs today cover the most common technologies that we use to deploy software, other than traditional RPM (and equivalent) software packages:

* Language-specific packages deployed directly into the OS, such as Python PIP and Ruby gems.
* Language-specific packages deployed into application servers, such as Java WAR files and NPM packages.
* Docker containers that consist of multiple "layers", each possibly including several RPM packages as well as other stuff, like individual copied files.
* Lambda functions that are built using their own custom toolset.

I am completely ignorant about the SWID ecosystem, so maybe the answer is Yes to all of the above (though a quick Google search came up with nothing). Any help from experts would be appreciated.

Thanks,
	Yaron

From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Friday, November 22, 2019 at 22:15
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "rats@ietf.org" <rats@ietf.org>
Subject: Re: [Rats] Reviewing EAT for enterprise/cloud use cases

On Fri, Nov 22, 2019 at 12:57 AM Yaron Sheffer <mailto:yaronf.ietf@gmail.com> wrote:
I have read the EAT draft, specifically with a “cloud” use case in mind. To clarify, what I'm looking for is the capability:

- To attest to software components that are running inside VMs, containers (either on VMs or bare metal), and anonymous containers (function-as-a-service, such as AWS Lambda).
- Such components may be deployed in arbitrary hierarchies (VM-in-VM etc.).
- Attestation of running (as opposed to installed) components. For example, container code may be pulled from a remote repository shortly before it is run.
- To support diverse roots-of-trust, such that when a hardware root-of-trust is unavailable, we can have a hypervisor or an orchestration server (e.g. Kubernetes) as the RoT, even if that means a lower level of trust.

I think in general, EAT can be made to fit these use cases, given its recursive structure. But not surprisingly given its origins, the draft would need quite a few changes.

* 1.2 (and 3.12): why not spell out that a submodule can be either a hardware or software component?
* 1.2: why *dedicated* root of trust, what is it dedicated to? A RoT may have other functions; a system may in general have multiple RoTs. The word "dedicated" is not repeated anywhere else in the document, nor is it explained.
* 1.3 continues to only talk hardware, e.g. when defining the "manufacturer". Software has a manufacturer too.
* 3.3: the notion of UEID is fundamentally incompatible with some component types that we would wish to attest. For example, the lifetime of a function-as-a-service container may be less than a second, and even if it has an identity during its lifetime, there is no registry or persistent record of this identity. Is a UEID required in this scheme?
* 3.4: hey, finally some software!

I think we still don't have a handle on identifying running software, and CosWID may not be the whole answer. CosWID is more like traditional software inventorying, and we need something that will cover dynamic modern software.

I'm going to write up some text for the CoSWID draft that would have a CoSWID in an EAT (CWT).  If the entire CoSWID (or even SWID) were in a claim, allowing you to add other claims, would this suffice for your use case?

I think I'll write a draft specific to what CoSWID looks like in an EAT as a follow up and would like coauthors.  I was thinking that might go into SACM, referencing the EAT work.

Best regards,
Kathleen

Thanks,
                Yaron

_______________________________________________
RATS mailing list
mailto:RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

-- 

Best regards,
Kathleen