https://lore.kernel.org/all/CAAH4kHarATWGg6S9DGA9a+yvSgLGY417xf2AZGO0ae=f2Z2aKQ@mail.gmail.com/

Copy/paste of beginning:

From: Dionna Amalie Glaze <[email protected]>
...
Subject: Attestation evidence collection "standard package(s)" effort
Date: Tue, 23 Jan 2024 10:44:34 
...
Hi all, I thought I'd start the conversation here about a concern I'm
hearing in various working groups. There are many software packages
folks are writing to provide in their VM guest images to gather
attestation reports and quotes, and no one feels they have a good
mandate to say "X package is what everyone ought to use" and that it
should be in most distributions' software repositories.
...

The Confidential Containers Attestation Service aims at being a modular, vendor agnostic and generic attestation service.

We'd like to present it to the CCC-Attestation SIG to get feedback on the architecture, flows, protocol and payload formats used by this project.

I recently spoke at the latest CCC TAC meeting on how we're building confidential computing support in existing container projects:

https://youtu.be/hSQC9GWvK-M?list=PLmfkUJc39uMjaB_I1dYW72I44kr9QzG_B&t=3355

In that presentation, I spoke a bit about the remote attestation server we built to support this work, known as keybroker. keybroker is still in its infancy, but I'd like to present its architecture to the Attestation SIG if given the opportunity. keybroker will become an official VirTEE-supported project at some point.

https://github.com/tylerfanelli/keybroker

In the meantime, I will add some documentation to the keybroker repository showing its architecture; and specifically, what it does different than existing attestation server implementations.

During the CCC event at FOSDEM, I had a conversation with @steffen-eiden about IBM's s390 attestation flow, and I realised how little I knew about it.

I felt it'd be good to socialize and share information about that with the wider CCC attestation SIG.

Steffen, who has contributed significantly to IBM’s s390x CC implementation, including kernel upstreaming and userland tooling, was eager to share some basic knowledge about the architecture and provide a detailed explanation of the attestation flow.

We discussed dates and he said he'd have the material for a 40-minute presentation ready by the end of March.

Can someone present about the technical details and specifications of attestation in "Intel Trust Authority"?

More specifically, there is a plan for Intel Trust Authority to support attestation for all TEEs (including non-Intel ones in addition to Intel SGX and Intel TDX). So my question is:

• Does it use Intel's RA-TLS for that? If not, then what are the changes to that protocol?

Proposal received from @nedmsmith

CoRIM Attestation Results (CAR)

The general objective is to show how CoRIM schema can be used to build an attestation results structure that serializes the ACCEPTABLE CLAIMS SET in a straightforward way.

Verifier provided claims, such as AR4SI summarization, follows the endorsement pattern.

I have example use cases that walk-through construction of the ACCEPTABLE CLAIMS SET to bring the audience along toward a logical conclusion that the Verifier generated claims follow the endorsement pattern (i.e., can reuse CoRIM schema).

It might make sense to structure the talk as a comparison between EAR/CAR. They are not that different.

As per RATS Architecture, Composite Device comprises of multiple sub-attester and a lead attester.

A more deeper discussion is required in CCC as to how different member organisation would want to see the Composite Attester Modelling and how the Format of the Attestation Token would span out meeting all the necessary security objectives

@gkostal 09/12/2023 SIG meeting:

How is "identity" represented for an attested environment? Can it be generalized?

• Especially if the attested environment is a confidential compute attested environment.
• And in a way that's tractable for a relying party to authorize against.

@gkostal 10/10/2023 additional details:

I am looking for an abstraction (similar to what AR4SI does for trustworthiness of an attested environment) for the "code identity" in an attested environment that:

• can be expressed in attestation results
• can be referenced simply by relying parties
• is independent of underlying TEE technology
• is stable over time (i.e., OS updates, new builds of application executable/binary/container, etc. do not change "code identity")

In essence, I'd like to look at this from the relying party perspective and figure out what's the ideal model for them, and then work backwards to see if/how it's implementable. For example, I could envision a relying party wanting to express a "code identity" as something like "The secret formula application authored by Coca-Cola" versus "The secret formula application authored by Pepsi".

A recent post by me on LinkedIn has generated an outlier amount of engagement and a spirited discussion.
https://www.linkedin.com/posts/markfishelnovak_machine-identity-in-cybersecurity-and-iam-activity-7111375919142879232-2Li2

The SIG should research and publish a document (in the form of a position paper) around the role of machine identity in overall attestation. There are two camps: one (in which I find myself) claims that machines are pets, not cattle, and the actual security principal worth tracking is code identity, as established by TEE attestation. In that view, machine identity has a very limited role (such as a claim resulting from mapping of an endorsement certificate into machine location for jurisdictions that restrict where data processing can be done). The opposing camp feels that even those parts of the hosting machine outside of the "confidential TCB" are worth attesting for an improved security posture.

The answer will not be universal across scenarios. For instance, privacy considerations may discourage the use of machine identity, while cloud scenarios might call for it.

@dcmiddle on Slack:

Dear SIG members,

The TAC has begun creating a set of priorities as we did for 2023.

Please consider setting SIG goals for 2024 that we can reflect in
the TAC. I think it’s helpful to get ourselves and our companies
aligned by having consistent objectives for the year.

Perhaps the Chairs could draft 3-5 goals so the broader SIG can have
a structured discussion. The final set should be no larger than 3-5.

Example goals:

• Identify and address obstacles in the interoperability of
  authentication, authorization and attestation for confidential
  computing
• Align definitions across other organizations like IETF, IAB, etc.
• Draft formal document describing CCC’s views on and definition of
  Attestation. See also this page.

You may wish to reference the original SIG materials for inspiration.

"configfs TSM" is a recently published set of patches to the Linux kernel (targeting v6.7, IIUC) that provide a common interface for confidential guest VMs to retrieve attestation reports from the host TVM.

"configfs TSM" aims at creating a common framework that supersedes the current per-vendor ioctl-based solutions.

It’d be nice if someone from the linux-coco community could come to one of the SIG meetings and present:

• use cases
• the framework
• the ABI (interface, semantics), and
• discuss Implementation choices (e.g., why configfs was preferred over sysfs)