ietf-wg-wimse / draft-ietf-wimse-arch

Draft of a WIMSE architecture document
Other
2 stars 7 forks source link

Terminology: Attestation #32

Open yaronf opened 2 months ago

yaronf commented 2 months ago

The wording here (Sec. 2) cannot be (and IMO, should be) distinguished from "workload authentication", where the basic identity of the workload is validated, even in the absence of any trusted environment.

nedmsmith commented 1 week ago

Attestation

Attestation is the function through which a task verifies the identity of a separate Workload. (TBD: sync definition with reference RaTS architecture)

RATS Arch chose not to define attestation formally. NIST has two definitions: (1) “The process of providing a digital signature for a set of measurements securely stored in hardware, and then having the requester validate the signature and the set of measurements.” (2) “The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.”

Definition (1) is consistent with RATS WG conventional wisdom (but they haven't officially adopted it). Definition (2) is typically applied in the context of a manual workflow process but has been used in the context of (automated) SBOM.

RATS Arch would describe SBOM workflows as "Endorsements" performed by "Endorsers".

The WIMSE definition is somewhere in between. RATS qualifies usage of the "attestation" term with "remote", which is helpful. Possibly, WIMSE should do something similar - as in "workload attestation"?

It may be relevant to describe WL Attestation both in terms of singleton WLs as well as a "workflow" of nodes. This suggests there is both a vertical (singleton) and a horizontal (workflow) aspect to workload attestation.

From a WL identity perspective, that implies there could be both a nodal identity as well as an identity for a collection / cluster of nodes that cooperate to implement a workflow.

A WL is typically deployed in post-manufacturing contexts (aka production networks). As such the RATS "Endorsement" terminology doesn't seem correct. Rather, each WL node would be regarded as a Relying Party (RP) that has as its input an Attestation Results message. But also, each WL node is an Attester. Hence, each WL nodes implements both the Attester and RP roles (as defined by RATS Arch).

A set of WL nodes cooperating to achieve a collective task will have a collective attestation context, which is the combination of attestation results from each WL node. Each WL node will have a collection of Evidences from each measured component that contributes to the WL image and execution and an Attestation Result for the node.

A collection of ARs therefore is needed to describe the trust for the workflow. A new concept is the idea that a summary Attestation Result may be needed that describes the trust properties of the workflow. An Attestation Results result (ARR) if you will?