Room: Hildalgo
Day/Time: 2025-07-23 14:30-15:30 CEST (60 min)
Scribes: Thomas Fossati, Muhammad Usama Sardar, Mike Ounsworth
14:30 - 14:35 Agenda Bash & Logistics
(5 min) Kathleen Moriarty, Ned Smith
KM goes through the note well, etc.
14:35 - 14:55 Update on CoRIM Progress (WGLC)
(20 min) Yogesh Deshpande -
https://datatracker.ietf.org/doc/draft-ietf-rats-corim/
YD provides an overview of CoRIM for the newcomers and (quite
impressive) lists early adopters.
Requests reviews.
Authors think the document is ready for WGLC.
Usama: you list AMD and Google. Are they the same? Is there overlap?
YD: they are those who provide CoRIM manifests to their customers.
[Zulip] David Black -- CoRIM being used in OCP NVMe SSD standard
(Solidigm will be first of many adopters). [minute-taker-note: this is
also reflected on the Early Adopters slide]
KM(chair) notes that this passes the bar of "at least two
implementations"; so we should not dwell on the details of implementers.
Added integer range
Added algorithm for domain membership: topological description of the
internal arrangement of a composite attester
Usama: Question about Composite Attester: the draft defines it as
either a composite device or a layered attester. Why layered
attester?
YD: A layered attester is a composite because it has multiple
environments.
Henk: I would go so far as to say that every attester is always a
composite, sometimes with one component. Defining it the other way gets
messy. But this is maybe just me.
Usama (in chat): I disagree. Specify in the draft.
YD describes the DM triple and its mapping in the internal
representation (i.e., ECT). New attributes and attribute values are
added into the ECT data item to support the DM triple.
Some complicated schematics are presented.
KM: Have all reviews been addresses? More reviews or WGLC? Cleaning up
the issues before going to WGLC?
Ned: 2 reviewers promised reviews at least IETF. Jag and Giri
Giri [Zulip]: Provided my CoRIM comments in GH. Will follow up in GH
on Henk's questions directly on the GH repo. I guess I may owe some PRs
too. Doc can go to LC in my opinion
KM: Inform when all comments have been addressed to proceed to WGLC.
14:55 - 15:05 Reference Interaction Models (WGLC)
(10 min) Henk Birkholz -
https://datatracker.ietf.org/doc/draft-ietf-rats-reference-interaction-models/
HB: Most of Usama's reviews have been reviewed. Almost 80% have been
tackled. Need help from Giri.
UMS: 80% of comments of my comments have been resolved?
HB: please check what we have addressed already. We can discuss the 20%
that is left to get agreement.
Can do it in September.
15:05 - 15:15 Key negotiation integrated into remote attestation
(10 minutes) Frank XiaLiang -
https://datatracker.ietf.org/doc/draft-xia-rats-key-negotiation-integration/
FX: The goal is to integrate key distribution and negotiation into RA
protocols.
Some overlap with aTLS, but more lightweight compared to that.
(only key management)
use cases include public cloud interaction with KMS, and supplying
secrets into the TEE for ML processing.
Yaron Sheffer (YS): Clarification: is it authentication of the KMS or
the client? or Both?
FX: KMS currently in the draft
Thomas Fossati (TF): Very interesting work. There are existing
implementations of some of the schemes, e.g., Key Broker protocol
in the confidential-containers project. They are receptive to
standardization, I suggest to get in contact with them and
cross-pollinate.
High level specification or exact protocol?
FX: Format: complete solution
UMS: clarification: is concrete protocol implementation in scope with
the current charter?
NMS: the charter includes the definition of protocols if there is a gap.
David Black [Zulip]: Please look at SPDM (Security Protocol and Data
Model) from DMTF that may be related to this proposal.
https://www.dmtf.org/standards/spdm
Yuxuan Song: in LAKE we have a lightweight protocol (EDHOC) that allows
attestation credential to be exchanged at handshake. It will be
presented on Friday.
https://datatracker.ietf.org/doc/draft-ietf-lake-ra/
UMS: Yuxuan's draft is good for IoT, but this is scoped to cloud
environments.
Henk: to be discussed. I think a thing is a thing, if the protocols have
overlap then they have overlap.
YS: key mgmt is an art on its own. When I read the RATS charter I don't
see key management as one of the topics. If you are going in this
territory, please update your charter. But I don't think this should be
in scope.
KM: I don't disagree.
MO [Zulip]: I agree with Yaron: KEX is crypto. RATS is not a crypto
group. I support the position that borrowing an existing crypto thing
from another WG could be ok, but definitely don't do core crypto
engineering here.
Andrew McCormick [Zulip] +1 on KEX design being separate from RATS
MO [Zulip]: Our AD is Deb. Maybe we need the AD to make a charter
scope call about KEX?
NS [Zulip]: Existing KEX designs don't integrate attestation, so there
is a gap.
15:15 - 15:30 CoSERV (Adoption) (Wednesday only)
(15 min) Paul Howard and Thomas Fossati -
https://datatracker.ietf.org/doc/draft-howard-rats-coserv/
PH: I am here to ask for adoption.
Updates since interim: new co-authors! support for different trust
models in the data model. addition of "stateful" environments to the
queries (based on CoRIM).
Future work: API bindings, starting with the RESTful HTTP model. Future
future: CoAP pubsub.
Update on running code: mainline corim package supports the latest
version of the draft. veraison's services now implement a new
"endorsement distributor" endpoint that implements a REST API.
two models are supported: direct (demonstrated for Arm CCA) and proxy
(demonstrated for AMD and NVIDIA RIM services). The work was presented
in the hackathon.
The case for adoption:
KM: covering quite a bit of ground, formats all the way through to
protocol.
How is it connected to the existing work? It'd be useful to see some of
the connections.
Paul: Diagram of connection to the existing works at RATS.
UMS: not clear how it is connected to all other drafts of RATS, in
particular multiverifier and posture assessment. How much is
architectural, how much is protocol. Is Aggregator a new architectural
block to the RATS architecture?
TF: CoSERV is concerned with endorsement and reference values.
Andy Draper: Isn't CoRIM already doing it?
PH: CoRIM is an assertive model. CoSERV adds query language to query
CoRIMs (and other RIM formats).
Andy Draper: If CoSERV is a mechanism to pull CoRIMs from a supply chain
entity, then I'd certainly support it. I will read the document and
provide more considered comments.
KM: a couple of action items (i.e., Paul to produce a pictorial
representation of where CoSERV fits in the RATS architecture, and
explain the relationship with multiverifiers and posture assessment),
and we can try to revisit and either do the call for adoption here on
Friday or on the mailing list.
Room: Patio 2
Day/Time: 2025-07-25 14:30-16:30 CEST (120 min)
Scribes: Yogesh Despande, Muhammad Usama Sardar, Mike Ounsworth
14:30 - 14:35 Agenda Bash & Logistics
(5 min) Kathleen Moriarty, Ned Smith
Currently missing slides for "Evidence vs Trusted Self-Assertions", and
"Proof of position". MCR believes he was removed from the agenda due to
time. Will submit slides during the meeting.
14:35 - 14:50 Conceptual Message Wrapper (WGLC)
(15 min) Thomas Fossati (TF) -
https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/
TF requests 3rd WGLC.
Explains changes which has more clear abstract, contributed by Hannes
Other additions to the draft on CMW Collection Type.
Usama requested clarification on protection in Section 4.
In v16, the properties were added.
PR#232: Text proposed by Ionut
Usama: Thanks TF for clarifying changes for "protection". Needs to
understand what security goals CMW can provide? If CMW already provides
authentication, then why Attested TLS is required at all?
We agreed on the list that we should never use Authentication stand
alone, it should be server authentication or with some other qualifier.
Mike Ousworth (MO) from Zulip: It's also not illegal to have
authentication at multiple layers (TLS and CMW), especially if it's
possible that those two authentications are done with different keys /
entities.
Usama: Removing authentication is fine for me, otherwise please add a
qualifier.
TF: Suggests Authenticity instead of Authentication.
Ned Smith (NS): Can we agree to resolve the conversation offline and
bring it to list?
TF: Rest of the updates
MO [Zulip] EST is an interesting example of this where you send a CSR
inside a mTLS session. It's possible that those are both signed by the
same key (which is redundant but fine), but also possible that they are
done with different keys (ex.: current key and new key, or where an
admin is registering a key on behalf of an end-user). I suspect
something similar happens with CMW-over-AttestedTLS.
14:50 - 15:00 EAT Measured Component
(10 min) Thomas Fossati -
https://datatracker.ietf.org/doc/draft-ietf-rats-eat-measured-component/
TF recaps on the old items.
WGLC comments have been addressed.
Mike contributed to Privacy Consierations
Two implementations of CMW: Keylime and Veraison
No questions in the queue for TF
TF Added raw values
TF thinks now they are feature complete
TF requests WGLC
KM puts out a call for a document shepherd. She is happy to teach
someone who has never done it before.
15:00 - 15:10 Remote Attestation over EDHOC
(10 min) Yuxuan Song (YS) -
https://datatracker.ietf.org/doc/draft-song-lake-ra/
Yuxuan from Inria Paris Introduction
Draft adopted by LAKE
Learned from Attested TLS
Draft for IoT Use Cases, fast and early establishment
Support for both, PP and BG Check Model
EDHOC became RFC last year with LightWeight Exchange protocol
EAD field in each message needs to be looked at
Usama: Related to first slide: Motivation is IoT Onboarding, trying to
understand how would RA would be helpful?
Y: IoT device joins the network, before that it needs to be trusted, so
most common use case for attestation.
Usama: Most common for IoT only!
Usama: Could you please say real world use case example to demo, it is
really required??
YS: Replied earlier to questions on Draft. Companay Telco Operator in
France. Used for Smart cities and Smart Homes.
Connect to Live Box, then they need to perform remote attestation.
Usama: Sufficient to add one use case to the motivation part
Y: Mutual Attestation over EDHOC sequence is explained
No change in EDHOC protocol
Usama: ATLS moved to Post Handshake, need to discuss about lifetime
JunZ: Swarm Attestation related question
Y: Not relevant to this draft.
Kathleen proposes to keep lake WG in the loop and Yuxuan to keep RATS
updated with the WGLC
15:10 - 15:20 Distributed Remote Attestation
(10 minutes) Donghui Wang (DW) -
https://datatracker.ietf.org/doc/draft-wang-rats-distributed-remote-attestation/
DW: network complexity creates problems for attestation to scale
DW: Solution: Publish everything to Distributed Ledger (Endorsements,
Attestation Results)
TF: Using the ledger as epoch bell, it is not clear, epoch bell has its
own pace, there seems to be no control.
Pace of minting EPOCH ID is not under the control of Ledger, is that
right ??
TF thinks this might be a bit problematic. Agreed to discuss offline
with DW.
Usama: Increasing complexity a lot, Slide 3 has key issues. Might be
implementation issue?
KM: Need to go to the list, initial promise was that load going to be
too high:
DW: Need to take offline
Andrew Draper (AD): What security the Ledger needs to provide? Clock as
a nonce.
Why everything needs to go into the BlockChain?
DW: One implementation of EPOCH ID,is via Ledger.
DW: Some advantages, we can share the information.
AD: Why extra layer is needed?
DW presents different DRA patterns.
15:20 - 15:30 RATS Posture Assessment
(10 min) - Derek Welski -
https://datatracker.ietf.org/doc/draft-ietf-rats-posture-assessment/
Kathleen introduces the draft.
DW: Current updates on draft.
TF: is there a typo on slides on referring to EAR because EAR is
attestation results format and not evidence format?
DW: Yes there is a typo, will make sure that will be captured ?
DW:Seeking feedback on real world use cases and other MDS References
Peter; What are the speicifc measurements that needs to be conduscted ?
Are these only RoT or some more upper layer behaviour?
DW: Three measurementent sets, DMTF, PCR and other third one.
KM: Can be mapped to known policy steps. Does it make sense.
KM: Establishing IANA Table to establish a registry
Usama: Welcomes him. What would be the overlap with Attestation Protocol
and wishes to contribute to the protocol
Henk: Compliance checks are good. Roots of trust section might become a
document on its own.
KM: Derek has a lot of text on the roots of trust. There could be a
draft for it.
15:30 - 15:40 Extending Trusted Path Routing: Issues in Runtime Trust
Assessment and Monitoring
(10 min) Ioannis Krontiris (IK) -
https://datatracker.ietf.org/doc/draft-rats-runtime-tpr-00
IK: Questions at the end, only have couple of slides, submitted a small
draft
IK: Proposed how to perform attestation based on run -time behaviour.
Draft goes through the challenges, discuss and take feedback
IK: Presents challenges on Dynamic Runtime Attestation
Usama: Trying to understand the use case for run time attestation? Is it
in the use case where something changes at run time
and you want to have some guarantee that the changes are captured? OR
there is some other interpretation
IK: Motivation is for this, is more trend of integrating cognitive
computing in network now. AI Agents is an example
More of the season logic inside the network, in a very dynamic way.
These needs services that needs establishment of
dynamic part.
Usama: is your use case NASR or other than NASR?
IK: I take your point. Right now it only takes consideration about
onboarding of devices. We need to think more further!
Peter Liu (PL): Not an author,Explain Motivation for NASR. To avoid
potential vulnerable devices that may lead to data loss or similar
threat
that was the original motivation.
PL: More generic problem than NASR
IK: Agrees to the point
15:40 - 15:45 Evidence vs. Trusted Self-Assertions
(5 minutes) Michael Richardson and Henk Birkholz
Henk introduces generation of Evidence.
Core issue is AR+E in the box is different TE, so can have an
independent option of what TE is doing.
More and more devices needs to provide evdence about itself.
Can we call this as Evidence ?
In a nut shell, RoT cannot provide Evidence about itself. This is a
common thing.
Most Important the Derived Key
So we came up with Endorsed Assertions.
They want to bring the topic up! Need more bashing!
KM: More time require, more time needed for terminilogy bash!
From Zulip:
Dave Thaler: if they can be configured, and nothing verifies the binding
to the configuration, then it may be insecure and wouldn't belong in
attestation. When would it be secure and how would you prove that?
Mike Ounsworth: Right. This is the core of the terminology debate.
I think we all agree that if you have a big rack-mounted-HSM, asking
that thing to describe its current state in a signed object is a useful
thing.
Is it "Attestation"? Probably. Is it "Evidence"? Unclear. Is it
"Endorsement"? Definitely not. Do we need a new word for it?
15:45 - 15:55 Remote Attestation with Multiple Verifiers (Adoption)
(10 minutes) Jun Zhang -
https://datatracker.ietf.org/doc/draft-deshpande-rats-multi-verifier/
Note: Update Progress on the Draft + Feedback from related Side Meeting
Clarifies the confusion with the older draft presented in Dublin
Mentions GDPR.
Mentions GPU+CPU as the use case.
2 Side meetings where "consensus" was developed.
Usama: 1. Would like to see the exact clause of GDPR which mentions that
multi-verifiers are required.
YD: Motivation. Issue is clearly highlighted. People can look up at:
https://github.com/ietf-rats/draft-deshpande-multi-verifier/issues/19
TF: CPU+GPU is a strong use case. Once you have split use case and not
vendor
TF: What is the scope of adoption? Architectural?
JZ: not specific protocols
Henk: Th
Usama: Following up on what Thomas said, CPU+GPU is an implementation
issue. It still belongs to the Verifier role.
Deb: Point of process as your responsible AD. You cannot have WG work
outside of the WG. You can have interims or design meetings but you
can't use Side-Meetings for this since they are not officially part of
the IETF.
[Deb will clarify this comment in the minutes later]
Poll:
yes: 8
no:
no opinion:
KM: Mixed interest. Interim for further discussion
15:55 - 16:05 PKIX Evidence for Remote Attestation of Hardware
Security Modules
Cure (10 minutes) Jean-Pierre Fiset -
https://datatracker.ietf.org/doc/draft-ietf-rats-pkix-key-attestation/
KM: Discuss on the list, more needs to be done.. Mixed terminology and
so on.
16:05 - 16:15 Proof of residency aware location claim for confidential
computing
(10 min) Ramki Krishnan -
https://github.com/nedmsmith/draft-klspa-wimse-verifiable-geo-fence
RK: Presented Sovereign Cloud AI Inferencing use case
refers to mcr discussion on list, complementary to Endorsement.
PL: Clarifying question: Trying to verify geo-location of accesing
device or datacentre?
RK: Trying to verify the attestation of workload host.
Peter: Picture is confusing
RK:
Usama: Data Sovereignty and host affinity is important, No strong
evidence in the draft other than yours..?
Usama: Would like to see motivation from regulations, other from authors
Usama: Quick other comment: Adding GPS to CCC Workloads can cause
security issues, happy to contribute to this work.
16:15 - 16:25 Proof of Position for Auditor managed Endorsements
(Low priority)
(10 min) Michael Richardson and Liu (Peter) Chunchi -
https://datatracker.ietf.org/doc/draft-richardson-rats-pop-endorsement-00
mcr: Endorsement
16:25 - 16:30 Attested TLS
(5 minutes) Muhammad Usama Sardar -
https://datatracker.ietf.org/doc/draft-fossati-tls-exported-attestation
Usama: Pretty much successful BoF, need to work on charter
Usama: What would be the concrete use case for Attestation Credential
refresh? That is the last issue to be solved.
Henk: DID Resolution is the actual use case for Attested TLS
Usama: Is this a concrete use case for Attestation credential refresh?
Thomas: Ionut on mailing list has already explained
Usama: What other security goals we should care about for Verification?
KM: We are over time at the moment, any comments, make them on the
list.
Usama: Seperate Mailing List attested-tls@ietf.org should be used.