Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminology: Attestation #32

Open
yaronf opened this issue May 5, 2024 · 2 comments
Open

Terminology: Attestation #32

yaronf opened this issue May 5, 2024 · 2 comments
Assignees

Comments

@yaronf
Copy link

yaronf commented May 5, 2024

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.

@hannestschofenig hannestschofenig self-assigned this Jun 17, 2024
@nedmsmith
Copy link

nedmsmith commented Jul 2, 2024

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?

@dhs-BI
Copy link

dhs-BI commented Oct 30, 2024

Re-reading this doc, this was one of the first things that stood out to me. Nowhere else in the doc is the term attestation used to refer to an authentication process. The definition refers to authentication. Attestations are provided by an authority over a set of data. For example, a FIDO attestation is not used for authentication, but to demonstrate the provenance of the hardware device the credential resides upon and its properties, such as FIDO certification or FIPS compliance.

The definition, as given here, is inaccurate and not useful in the context of the doc. I urge the authors to give serious consideration to removing it entirely from the document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants