Room: Van Horne
Day/Time: Thursday 2025-11-06 17:00-19:00 EST (120 min)
Scribes: Muhammad Usama Sardar, Thomas Fossati, Mike Ounsworth
17:00 - 17:05 Agenda Bash & Logistics
(5 min) Kathleen Moriarty, Ned Smith
Chairs: would like to see more reviews. We need to clear out a number of
documents that have been sitting a bit too long.
Chairs: asked for volunteers to Shepherd documents; chairs can help in
the process.
Looking for shepherds for following 3 drafts:
Henk: MCR volunteered to shepherd the network subscription doc.
Kathleen: OK.
17:05 - 17:20 Concise Reference Integrity Manifest (WGLC)
(10+5 min) Yogesh Deshpande - draft-ietf-rats-corim
At IETF 123 we requested WGLC. We received review feedback and valuable
comments.
Deb: we can request early reviews now if you want them, which one do you
need?
Please send comments to the list and they will be tracked through GitHub
issues and addressed.
Pull Requests (PR) also submitted.
Still a few open issues open that will be addressed in the few months.
New features addeded in -09:
CWT claims added to the protected header (interop with SCITT) --
this is preferred over the current method which defines a CoRIM
specific COSE header called "meta" a.k.a. corim-meta-map.
Added CoRIM verifier process diagram.
Added ACS Matching Condition (ACM) to the diagram.
Giri: Question for chairs: do we need to go through WGLC and IESG? can
we do concurrent?
Kathleen: The order of reviews is very intentional, it can't be changed.
Cross-area reviews can help improve the quality of the doc so to
minimise the chance of later IESG DISCUSSes.
Deb: Early reviews.
Usama: Asked Giri whether there is some urgency so we can prioritize it
and give you early reviews.
Giri: There are active implementations and dependencies in the industry
on this specification reaching a stable stage.
17:20 - 17:35 PKIX Evidence for HSMs
(10+5 min) Jean-Pierre Fiset - draft-ietf-rats-pkix-key-attestation
Changes since IETF 123:
Clarified "presenter" role:
Usama: (clarifying question) What is the "attestation service" in slide
3(4?), is it the Attesting Environment (AE)?
(from chat) Mike: HSMs don't have an Attesting Environmenet (AE) the way
that RATS traditionally thinks of one.
Usama: An evidence made of entities made of attributes is not
particualrly RATS-y. Considering changing entity to subject. Also the
presenter role could be taken out of this spec and referenced.
Dave Thaler (chat): My (possibly wrong) understanding is that HSMs
protect the keys but can't actually attest to the correctness of
anything outside of the HSM, is that correct?
Jean-Pierre: Correct. HSM can only have access to what it sees.
Henk B: Only Attesters can produce Evidence. Attesters have at least one
AE and at least one TE.
Jean-Pierre: Attesting Environment (AE) and Target Environment (TE) are
the same environment.
(Chairs note: A root-of-trust is when an AE and TE are the same
environment; though RFC9334 tries to avoid using Root-of-Trust
terminology.)
Henk B: This is different from what was previously said that there is no
AE vs. now that there is no isolation between AE and TE.
Dave Thaler (chat): "This does not fit cleaning into RATS" => document
may not be in scope for rats.
Dave Thaler (chat): @Kathleen an info draft explaining the architecture
(i.e. more than just the HSM, but the larger context on the rats
attester side) in rats terminology. What I'm hearing is this draft
doesn't do that but I haven't read it to check.
Dave Thaler (chat): @Mike great to have RATS review of non-rats docs, if
that is the goal then excellent, thanks for the visibility and
presentation!
Mike Ounsworth (from chat): We have tried very hard to include the PKIX
<-> RATS terminology mapping within the document. Review of that
tutorial content would be helpful :)
Mike Ounsworth (from chat): So, we (the authors) believe that this fits
within RATS Architecture enough that it's useful to do this work
within RATS. For example, we are borrowing heavily from EAT, and EAT
intends to upstream many of our key attestation claims (content and
semantics).
Mike Ounsworth: So this is exactly the "Root of Trust" nomenclature
landmine that we're trying to avoid. Within the HSM world, we know what
this thing is and why we trust it. This does not fit cleanly into RATS.
We've litigated this multiple times in multiple centa-threads on RATS
over the past year. Can we please move on?
Dave Thaler (chat): I agree it would be a BAD IDEA to sign lies.
However, since it cannot tell the difference, I take it as you saying
that having the server sign anything from a server (or other HSM
client) is a BAD IDEA unless the information is securely attested to be
trusteed. Thats fine and is a stronger statement than I was making :)
Kathleen Moriarty (from chat): @Dave, I suspect it would be limited in
what it would sign given the connection and role of an HSM
Mike Ounsworth (from chat): What? Our document provides a way to ask the
HSM: "Hey HSM, can you please describe Key #17" "Sure. Key #17 has this
public key, is flagged NonExportable, and was generated locally here.
The HSM platform is currently running in FIPS mode. Signed: the HSM's
AK". Absolutely 0% of that content came from outside the HSM hardware,
except the request that kicked it off.
Jun: two remarks:
Jean-Pierre: (inaudible remarks :-( )
17:35 - 17:55 Remote Attestation with Multiple Verifiers (Adoption)
(15+5 min) Jun Zhang - draft-deshpande-rats-multi-verifier
The speaker clarifies the scope of the draft.
In-scope:
Out-of-scope:
Other Considerations:
Use case 1: CPU + GPU
Usama: (clarifying question) Why are the vendor not willing to release
their policies? This is not good for open source ecosystem.
Jun: it is a question of Intellectual Property (IP) where they do not
want others to know.
Yogesh: it is not just a question of policy, there are also cost
considerations
Is it possible to issue a call for adoption?
Kathleen: the priority is clearing the document pipeline.
(Poll): Would the working group like to adopt this draft after we clear
out a few in queue? Is this work you are interested to see done here?
Usama (voted no): it increases the security and privacy problems.
Thomas: work in progress implementation of the hierarchical pattern in
Veraison.
Usama: before we adopt, we should have proper privacy and security
considerations.
Henk: please contribute, suggest text.
Kathleen: Suggesting text does help get your stuff in quicker and being
polite also helps get your stuff in quicker because people will respond
to you quicker if they don't have to cool down.
Yogesh: Some threats have been addressed; others are welcome.
17:55 - 18:10 Key Negotiation Integration (Adoption)
(10+5 min) Jun Zhang - draft-xia-rats-key-negotiation-integration
Thomas: Veraison has an Attestation Request message in the RATSD(?) API.
Let's make sure that what we have fits your use case as well.
JP: On slide 1, there is a claim that this would enhance performance,
how?
Jun: (missing text).
Kathleen: Attested TLS work has moved to SEAT WG. Why should this work
come here?
(poll):
Usama: aTLS has moved to SEAT, but we are not defining a protocol in
this document. It may be used as a guidance protocol for key management.
18:10 - 18:30 Composite Attester (Adoption)
(15+5 min) Michael Richardson -
draft-richardson-rats-composite-attesters
Premise: RFC 9334 define a "composite attester", but it is not inclusive
enough of the many different ways in which people want to do attester
composition.
Define different "classes" of composite attesters: Class 0, ..., Class
n, that describe the different modes of composition.
Are these classes complete? If something is missing, send some text or
submit issues or suggest Pull Requests (PR).
Yogesh: biweekly calls with lots of contributions from many different
people.
(Acknowledes contributors.)
Jun: (makes suggestions):
MCR: we should go down one level to identify smaller, more fundamental
components that can be recombined.
Jun: Two Attesting Environments (AE): is it a class or not?
Yogesh: how you present these (missing text?).
Laurence: Compared to reality, this is quite simple. There are probably
a lot of other stuff.
MCR: targeting for 90% rather than all.
Thomas: I hate taxonomies but I like this work. Keep on working on this.
18:30 - 18:35 Veraison Hackathon Results
(5 min) Ken Takayama
Ken presents their hackathon project:
Secure software provisioning with TEEP and Veraison.
Objectives:
Yogesh: [We] welcome your contributions.
Thomas: Thanks for EAT and EAR feedback. Issue has been opened for
discussion on per-protocol claims.
Giri: If the Attester left out the EAR option, would it work without
changes?
18:35 - 18:50 Guidelines for Security Considerations of RATS
(15 min) Muhammad Usama Sardar -
https://datatracker.ietf.org/doc/draft-rats-sardar-sec-cons/
Usama: described security considerations goals:
Henk: which drafts are you talking about?
Usama: The ones which are mentioned on slide 1
(draft-ietf-rats-epoch-markers and draft-ietf-rats-ar4si).
Usama: ...continuing with the goals:
Usama: what would you find useful as a draft author?
Giri: rather than focusing on docs that are in early stages, focus on
documents that have progressed to RFC stage. For example, RFC9711
inherited from CWT which in turn inherited from JWT and used the cti
claim for anti-reply purposes which has caused problems.
Usama: Documents mentioned on slide 1 are motivational and not the only
focus, e.g., draft talks about RFC9334.
Deb: if your goal is a template for sec considerations, I would put it
somewhere else than an RFC. This sort of document must be nimble, and an
RFC is too static to be useful.
Also do the WG really wants to spend time on the threat model? What is
the value for developing a threat model for RATS?
Mike O: don't do this. This is a much bigger problem than it looks. The
return would be exponentially lower than the effort you'd put in it.
Daniel Migault: an everending draft is not useful.
Usama: Every draft has security consideration. So, in this sense, every
draft is neverending.
MCR: if the goal is a template for "* considerations", that's how we
did it in ROLL. we did via "applicability statements" with a number of
sections containing questions that were easy to answer -- see draft.
Consistency helped reviews over different documents.
We also did a consensus call within the working group for the ToC.
Michael P: the sec cons RFC is old and many things have changed in the
meantime.
18:50 - 19:00 Open Mic
(10 min) RATS Chairs
Henk: Reference Interaction Models (ReIM) draft update. Addressed all
the issues, except for the shepherd's comments. :-( We apologize. Usama
filed a new issue.
Usama: It's not a new issue. It's more than one year old issue.
See the first specific comment in Issue 58.
One issue is left.
Deb: status of CMW?
Thomas: we think we have addressed all comments. There is still a
pending question to Peter (Gen-ART reviewer).
Deb: I'll ping Peter. W
Room: Agora
Day/Time: Friday 2025-11-07 11:30-13:00 EST (90 min)
Scribes: Muhammad Usama Sardar, Jun Zhang
Chat Watcher: Jean-Pierre
11:30 - 11:35 Agenda Bash & Logistics
(5 min) Kathleen Moriarty, Ned Smith
Kathleen: Be polite for your comments. This helps comments integrated
faster.
Seeking solid reviews.
11:35 - 11:50 CoSERV Progress Update
(10+5 min) Paul Howard - draft-ietf-rats-coserv
Recap of CoSerV:
-Support flexible interactions and transports.
-supporting real-world supply chain complexity.
The speaker will take clarifying questions at the end.
Speaker's main points:
Describes updates and future work:
Client-side and server-side:
Usama: Where is the aggregator role discussed in the draft (page 5)?
Paul: Aggregator is not a fundamental entity inside CoServ. That is a
possibility however. The Aggregator role is implicit.
Usama: could we remove aggregator from the draft (as it is an
implementation)?
Paul: The data model needs to be rich enough to offer the choice.
Thomas: We do not want to drop aggregator from the draft as we want to
offer it to the consumer.
After the discussion closed, much was shared on the chat about the
necessity of the aggregator role and whether it should be part of the
draft.
This discussion shall be continued on the mailing list.
12:05 - 12:35 Harmonizing RATS with WIMSE
(30 min) Mark Novak - draft-novak-twi-attestation
11:50 (actual start time)
The speaker will take questions at the end.
Key points:
Workload identity:
Flows:
Security and Privacy consideration
Solution
1) Key Source: self-generated
Yaron: WIMSE context.
Mark: Worry that attestation results are fragile and unsuitable for
entire classes of deployments.
Yaron: Some auxiliary data is passed separately. Modular (missing text).
Mark: Your counterparty may have different requirements.
Giri (AMD): Live migration case doesn't provide security values between
sending and receiving machines. Why separate identity is required? AMD
SEV-SNP have identity (ID block in AMD)
Mark: No hard dependency on WIMSE. Can't have something AMD-specific.
Giri: Workload may present the same credential again and again even
though (missing text).
Henk: AMD practical implementation solution and maybe abstract. Maybe
the Claims Mapper can be part of the Verifier appraisal procedure?
Mark: Attestation Result from Verifier is not necessary the one that RP
want.
Since short time, Kathleen presents Usama's concerns about terminology
mismatch with the RATS terminology which will be taken to the list.
Giri (in chat): Workload ID is provided by a credential issuer to an
attestation obtained at a point in time. The workload's security state
can change over time but the workload can still present the same
credential it has been issued beforehand. I don't see a mechanism in
WIMSE at least for revocation of the credential based on changes in the
security state of the workload, because the workload itself needs to
notify the issuer about the security state change.
12:20 - 12:35 Remote Attestation and Geographic Evidence / Attestation
Results
(15 min) Michael Richardson, Ramki Krishnan -
draft-richardson-rats-geographic-results
4 relevant documents
RP doesn't need to know how it is produced.
Geographic results can be delivered in 3 formats
Goal: to provide interoperable, cryptographically verified location
results.
Use Case: An AI Agent (Devsecops admin persona) is assessing the
trustworthiness of enterprise VPN users.
The Agent’s geography is important, because it will be provided with
sensitive security information.
Use Case: Network Attested Secure Forwarding.
Usama: What is the problem you want to solve? How Verifier judges that.
Michael: Get a common result from the Verifier.
MCR:
Mark: Location?
Diego: How we build the Evidence and probably ptp belongs elsewhere.
Henk: How long is this statement valid? What is the source of Claim?
Method of registry of location? How do we deal with multiple
geolocations?
Ned: Is that not out of scope?
Deb (no hat): should be extremely careful about Privacy considerations :
can it be used or abused that way?
12:35 - 12:55 Threat Modeling for RATS
(20 min) Muhammad Usama Sardar
Discussion on Threat Modeling:
Replay of stale evidence across multiple connctions
Replay of stale evidence within the same connection
Relay attacks:
Diversion attack
Discussion on the properties of a threat model
Mitigations:
Replay
Binding of evidence to connection
Specifications to be improved:
Usama warns the group that RATS specifications are not written for the
following:
--- Question period ---
Henk: I agree with slide 7 in general.
Henk: Henk does not understand diagram on slide 3. What is the left-most
entity?
Usama: It is another connection of Verifying Relying Party, as the
arrows comes out from Verifying Relying Party.
Henk: Replay issues are a known problem. Conveyance channel binding and
maybe some additional form of freshness is required, obviously.
Kathleen: Please put those issues in GitHub.
Usama: They are already RFCs, so which GitHub? Kathleen to explain later
(on the list).
Henk: If the attestation key is leaked, then all is compromised. Is that
the case with TPMs? (I think not.)
Usama: Here, it is saying AK of any machine vs. a specific machine.
Henk: For "Unprotected evidence", please see RFC9781.
Jun: Replay attack mentioned is the Time of Check Time of Use (TOCTOU)
attack.
Jun: when binding evidence with connection, the privacy needs to take
into consideration as the attester may be tracked.
Jun: Need to have a balance between security and usability. For UCCS, at
least current solution provides better security than nothing.
Jun: for binding destination in the attestation result, some protocols,
like RA with Oauth has addressed it.
(running out of time)
Dave: Agree with slide 7
12:55 - 13:00 Open Mic
(5 min) RATs chairs
Kathleen: focused time; have interim on security considerations. Will
see on the list the right place to put the issues.
Chairs thank the note takers.