Session Date/Time: 14 Sep 2026 16:00
[00:00:07] Ned Smith: K. So I count seven talks, not counting chair slides. I have six sets. What am I missing? Camilo Posada? Is there someone given the trajectory based recognition of identity proof talk? I think that's the one I'm missing. Okay. Well, hopefully, that will come in in a minute.
[00:01:04] Mark Novak: Quick question. So I submitted the draft that I'll be presenting on Friday, the the one. But on the interim meeting schedule, it has it's that it's not under Internet drafts link list.
[00:01:20] Ned Smith: Yeah. I didn't get a link for that. Do you have one? Or
[00:01:28] Mark Novak: Yeah. I I have a link.
[00:01:31] Ned Smith: Can you just post it into the chat so people get it?
[00:01:34] Mark Novak: Yeah. Absolutely.
[00:01:37] Ned Smith: Alright. So let's get started. We need a couple of notes takers. Could we get some volunteers to do that?
[00:01:54] Muhammad Usama Sardar: Hi, Ned. I can help. I,
[00:01:57] Yogesh Deshpande: I can help, but I might be a little off in some time in the middle. So,
[00:02:01] Ionuț Mihalcea: you
[00:02:01] Yogesh Deshpande: know, that's fine. But but I can help, certainly.
[00:02:04] Mark Novak: I will try my best. Okay. So
[00:02:08] Ned Smith: let's go with that, and I will kick this off. So Kathleen joined. Let me hang on. Alright. Can people see me sharing anything? Alright. So this is the note well. I think everybody here has probably seen it. If you're not familiar with it, please review it. RFC seventy one fifty four. It describes the context in which your contributions are made to the ITF. There is a code of conduct in in seventy one fifty four as well. But basically, in summary, it's extend respect and courtesy to your colleagues at all times, have a personal discussion. And remember, we're devising solutions for the global Internet that meets the needs of diverse technical and operational environments, and be prepared to contribute in an ongoing work. So we appreciate your contributions. Thanks to Yogesh and Usama for their volunteering to take notes. And this is the link for the material. So if you get lost, go to the rats chair the chair slides, and there's the link or just data tracker meetings, rats. And with that, we will jump into the first talk. And let me get that up here. Usama.
[00:04:08] Muhammad Usama Sardar: Okay. Should I start?
[00:04:14] Ned Smith: Yeah. Go ahead.
[00:04:15] Muhammad Usama Sardar: I think Okay. So, yeah, welcome, everyone. I'm going to present the draft that we have with Songbo Bu and Serhii Nikolaichuk just recently joined, and I really want to thank the people who have provided feedback on this, specifically, Henk Birkholz, Marcos, and Tobias. So so, Ned, are you going to move the slides, or do you I think you are controlling the slides. Right?
[00:04:45] Ned Smith: I think I can I think I can give that to somebody, though?
[00:04:50] Muhammad Usama Sardar: So if you can give me, that would be quicker for me.
[00:04:53] Ned Smith: Yeah. Okay. Just remember how to do it. If not, I'll just click it for you.
[00:05:02] Muhammad Usama Sardar: Okay. Sure. I'm going to describe the why and how since the March meeting where we presented it in the last interim that what we have changed and which direction we think is the most beneficial for the Ritz working group. And then I'm going to describe the or make a request for adoption. Next one, please. So this is the request that we made recently, and I have highlighted a few parts which are which people have actually found it to be useful in their own work. This is the email from Tom from July 13. For instance, the highlighted parts directly from the guidelines of the section five through eight. Okay. I got control. Thanks. And in four of their own specifications in which the guidelines we provided in the draft already were very found to be very helpful. And then also the highlights at the bottom, like, explicitly designed with CVE-2023-3697 in mind, and that's really the purpose that keep the security considerations in mind while designing the specifications, and then it's going to be secured rather than writing the security considerations. At the real end, when everything has been done, it's quite difficult to do anything at all at that point in time to make some real changes. Structured defense against that relay class attack is what they already designed at the in their design. So continuing that email, so two added level findings, three warning level findings. They hadn't came across these during their revisions, and there were gaps in the explicit track model, authentication level, specificity, undefined terms, and real gaps in the guidelines that were caught by the guidelines provided. And that's a recent email from Serhii Nikolaichuk, which was kind of explaining what the draft section was explaining, the relay attack specifically, and how it was useful for that specific draft, which says that a relay can sit in between the attester and the credential authority. That's basically the draft from Mark and his co authors. While every check above still passes, like, the checks that they had still would pass, but the relay attack would still remain. And then at the bottom, I have the basically or actually, Serhii Nikolaichuk has this explained, which is that the value derived from the task transport shared secret, the RFC nine two six six TLS exporter into the freshness field and say so in the security considerations. That's basically how different drafts can benefit from this right from the beginning. And as I said, this was written before he was the co author of this specific draft, which I invited him. Continuing this to explain the broader spectrum, so to say, that where we see this work going forward, as I said, since March, we see most of the benefit happening at the problem statement as presented here that we want secure computations. And how we can check these is that we can check the connection and the remote environment, and that's basically the two guarantees that we need. So it it's how to exactly check that before releasing the sensitive data or the protected data is basically what is shown in this specific figure. And just for simplicity, I'm combining the verifier and the relying party rules. Of course, they can be separate. They can be as in the REx architecture. On the right, you see the tester as before. And what's different here is that it's the confidential computing environment, meaning that it needs to have some security guarantees about from a confidential perspective that the data is kept confidential from the cloud service provider and so on. So which is very much within the threat model or the scope of Ritz architecture, Ritz working group. And I have here, like, the three different levels of where the security considerations we see are useful and where they can be applied for several different drafts. And as as is shown in the figures, like, labeled as number one is when the test generates that evidence, it has to be bound that underlying connection. And that's really important because if this is not the case, that would lead to diversion attacks. That could lead also to the relay attacks. And on the right side with the verified and the lying party, because I have combined that, of course, then the relying party and the verified decisions appear now together. And one of the things that is here is the verified enforcement that should be enforced. I will explain also in the next slide to give you a quick idea is that it will check the evidence, of course. It will appraise that evidence, but it also has to essentially enforce that the expected binding is there, that it bounds to the the binding value is provided and and is also bound to that specific connection with which it is sending that sensitive or is going to send that sensitive data before releasing it. And relying party is going to make that decision for data release. And on the coming back to the right side again, the workload authorization, that's the third level at which we view this work happening, like connection binding, verify enforcement, and then the third level is workload authorization. It's not timing. So just to clarify, it's not the temporal behavior. It's representing different levels at what which things can go wrong and at levels which one has to be careful in the security considerations. And the specific thing to note here is that the workload authorization should enforce that the applicable policy for that specific workload is enforced and is consistently applied in all the parts that's for that competition to happen. So with that, basically, after all of this has happened, the three levels checks, it can send over the sensitive data after or release that sensitive data as it's written here, it can get back the results from the a tester, and it can get to trust these results based on all of these checks that it has made. If all the three levels of the things pass, it can approve it to be correct. And as I am going to explain it, these are just illustrative examples, meaning that we are not claiming that these three levels, if someone satisfies that, they are secure. Like, the system could be the ecosystem of Rats could be at different other dimensions as well. But these are three important, let's say, criteria that we think are important to emphasize or the starting point for us to meet this draft into something that the working group can give specific feedback on. So from that perspective, basically, the first one, as I explained, that if the if the if the connection binding is not there or if the evidence is not strongly bound to the connection, the underlying connection, the problem that can happen is that there could be a man in the middle or a relay attack happening, and the two participants in the protocol will not identify identify that there is a third party in the middle, the attester will, sorry. The the the the verifying line party combining the two roles will continue to believe that, basically, that is talking to the attester itself, but there is someone in between which is actually getting it and the connection establishes to that, basically, the man in the middle or the relay attack to be more precise. The second point, verify enforcement. As I said, that the the expected value from the verified API, it should be provided, and it should be that meaning that if it is absent, it should be it should be disconnected. It should not establish a connection. Or if there is a mismatch, it should again discard this, and it should not proceed with that. So the expected value or the reference value for that specific artifact should be there, and it should be correctly compared. The third level of checking is that it should enforce that applicable workload policy is applied on every accepting part, whatever the verifier will accept. And, eventually, then the relying party will accept for each possible parts the applicable workload policy was correctly applied. And that's basically a limit a kind of a guidance for also for the implementers to implement it correctly. So coming to the adoption part, from the author's lens, we what we see here, the draft adding value is a a shared security baseline, which is to say this will be shared among different drafts just like RFC nine three three four as the former foundation, and it will add on top of RFC nine three three four and also on top of RFC three five five two, like, the taking that as the baseline. And then use that as the baseline, like, providing this as foundation for other drafts to actually use such that just like we use RFC nine thirty four, this draft will actually help different draft authors. I will come to that point. And, Kathleen, I will just come to you in, I think, a minute or so. Let me please finish this slide. So rest started from a security considerations perspective. How we view it security considerations perspective is that it is talking about two different things. Number one, namely the formats in which format the any artifact of Ritz is conveyed over to the parties or the rules, a tester, verifier, a line party, and then the convenience protocols, how these artifacts are actually conveyed between these rules. And there are different possible combinations and, like, background check model, passport model, and these are exemplary. They can be different ones. So how these convenience protocols happen are part of the charter and what we see value in or what this draft actually adds value in in our view is to provide a security considerations baseline for both of the above, not only for convenience protocols, but also from the format's perspective. Like, format meaning that, for example, that let let's say the a specific format has to contain a nonce such that the replay replay protection is kept consistent. And, also, like, it should contain a specific binding. The number one point I had in the in the in the the figure I showed, that was basically showing that this is evidence has to be evidence has to be correctly bound to the underlying connection. So these are the kind of things that basically are going to be covered in our view. And it's the pro or the the benefit, basically, we see is the shared burden that we do not kind of keep messing around with the authors and so to say we provide the guidelines which are shared among different drafts, what is common to most, if not all, of the drafts. And this will lead to kind of, like, focusing on our own strengths rather than messing around with each other would be, I believe, a better way to do it, which will be that we focus on the security considerations and authors focus on their own work, and then we import some of the security considerations in different drafts, like just like the way the the RFC nine three three four is, used. So other draft, for example, like, the two mentioned here can reference these applicable checks and state their assumptions and remaining risk and so on. So
[00:18:20] Ned Smith: So I'm gonna jump in here. You you wanted five minutes for discussion. We've got a minute, less than a minute, less than a minute and a half. So do you want that discussion? Or
[00:18:30] Kathleen Moriarty: I need to to us share. I'll use the last minute. Muhammad Usama, this draft does not follow the guidelines you were provided. So I provided as chair specific guidelines in Madrid. Your notes, you were the notetaker. It did not accurately reflect what happened on the recording. I suggest you go back and listen to it. The request was to make sure that you could do you could do a draft, but that draft would be an updates draft. It would be very simple. It would follow an update structure, and then we would have a wiki where we could establish a template of agreed upon advice that would go into other documents. The draft as written is not something we could adopt. If you take a look at section 1.4, it's not collegially written. And so that's just another point of contention. I don't wanna introduce something like that into the working group because it will not lead to healthy discussions. So that that's a nonstarter right now to put noncollegial messages within a draft. So let's go back to the advice that was published or that was provided first by me as a chair in Madrid stating we could do a wiki for general guidance like all of the other working groups following the best practices for the IETf, the way it's been done for things like NetComp, Yang, and and other protocols where you have that guidance, you follow a template, it's agreed upon. Great. And then where corrections are required, we do a simple updates draft in the format that an updates draft occurs that's very factual, that doesn't introduce any criticism of other drafts in the way that's been done. You simply state this has been found to be vulnerable and because of x y z, and here is the updated text. And you get that agreed upon, and that's a far more collegial approach. So if you wanna come back with that before the next meeting, we can consider that.
[00:20:51] Muhammad Usama Sardar: Sure. I I I I just want to add a quick note here that the last sentence I had was exactly on this point that the proposed corrections and the security concerns are basically illustrative. They are they they can be removed. It's not something that we are saying that they are set in stone. But point here was that think it's clearly written in the draft. It says that it is talking about three different points. And the one I'm presenting here is not the corrections or the security concerns in red stuff. That's what you are emphasizing. And we are saying basically exactly or talking to what you are saying that these two points can be removed. They are illustrative. What we are focusing here is on the point on security guidelines rather than these two points. And my whole presentation was never talking about any of these two points. What we are requesting the working group is that there is a need for guidelines or the baseline security considerations other than what other than the criticism or whatever word you use for that. So
[00:22:01] Kathleen Moriarty: Section 1.4. And I couldn't read beyond that, and I would expect nobody else in the working group to read beyond that. So let's take this offline. We're over time already. You've been provided guidance, and we would greatly appreciate you following the guidance and staying within working group norms. Thank you.
[00:22:20] Muhammad Usama Sardar: Okay. Thanks.
[00:22:34] Ned Smith: Okay. Now I gotta get to the slides. What was the name of your talk?
[00:22:56] Yogesh Deshpande: CoRIM Profile for confidential computing architecture. Yeah. So, I have eight slides. I requested Ned to extend my slide time from five minutes to ten minutes, and he has kindly agreed. So I would request I would take questions in the very end of the last thirty minutes of the spare time because I don't believe that, otherwise, there is a risk of reject holding and causing the slides to derail. So, basically, everyone is quite familiar here. CoRIM stands for concise reference integrity manifest, data format, and information model to convey reference values. And here, we are presenting a specific profile of CORIM, which is applicable to Arm CCA architecture. So here is a top level diagram which explains the CCA attester where you would see a root of trust, the hardware and food security, which is, which collects the claims for the one layer above, which is the real management monitor, which then, in fact, acts as root of trust or kind of a claims collector for the realms which run on the top. RHEL provides the confidential VM or the confidential computing architectures, virtualized virtualization framework, and then the combined evidence is sent to the remote verifier. So you have a layered tester as per the RFC nine three three four, which has a platform attestation and realm attestation combined together. So we need we will talk about the endorsements or the reference values required to instantiate this profile. So Oops. Sorry. It's it's clicks a little slow. I need to adjust.
[00:24:44] Mark Novak: Okay. Yeah. Yeah.
[00:24:49] Yogesh Deshpande: So, effectively, it's quite obvious that we'll talk first about the platform endorsements. So when I say endorsement, it means endorse endorsed values and reference values. We call it endorsements. So enrollment for CCA platform has a CCA platform identifier and a platform instance identifier. The instance varies for, it's an instance identity, meaning for multiple instances of the same platform is instantiated, and the platform reference values are anchored to just the platform identifier, the class identifier, while the instance identifier and the platform identifier together anchor the CCA attestation verification keys, which is effectively acts as a root of trust in validating evidence, as received from the CCA attester. And the CCA platform is identified by CoRIM profile, which which is expressed in the CoRIM profile format. So let us look at the how the enrollment is instantiated. So the CCA platform is identifier is ex is known as CCA implementation ID, and it is expressed using the tags bytes of fixed size 32. So we are using the base CoRIM type. Not anything no extension slot is required. Just use the standard tag bytes of the CoRIM, and we have expressed that. And the CCA instance ID is using the EQE ID of type rand to express that. So all the base types are used to express the implementation and the instance. And the reference values comprise of the CCA software components, which essentially form the platform root of trust and the RMM software components, the platform configuration, the root trusted base, both platform root of trust public keys, and the platform manufacturing configuration. These are the reference values which I'm going to talk in a minute. And the platform attestation key is expressed as a crypto key type choice of base 64 key type. So as I mentioned, the software component is exactly using the measurement values map of the current draft entries. There is no such deviation except on the fixed size length of the digest. So you use the version to express the component version of the software component which is used. The digest express the digest, of the CCA software component, and it is of, digest can be of thirty two forty eight or one twenty eight bytes long. The name is the component name, which is optional, which could be like a bootloader platform, boot of trust, or any any suitable name associated to the component. And the, signers is the authority behind that software component is expressed using the crypto key. For this profile revision, only one crypto key type. Only one entry is required or sup supposed to be provided in the software component signer IDs. So pretty much everything is used from the base scoring profile and instantiated here. And the platform configuration is, each of these uses an empty of type CCA platform config. The previous one uses CCA dot software component as the m key. So similarly here, the type is platform config or platform manufacturing config or the CCA platform, root of trust public keys has, the name of the bank, which uses the public key. So it's, life cycle like, Centimeters or DN, the chip manufacturing or device manufacturing is the life cycle. And the configurations is expressed using a tag draw value mask where the masks have which are all set one to express the exact configuration components. And manufacturing configuration follows exactly the same, And root of trust public keys are expressed as digests. Now the realm is the virtual enrollment or the, confidential VM, which is instantiated. So it has its own reference values, which is how the realm was instantiated. That is the initial measurements at the time of activation of the realm and the extended measurements that of the software that runs inside the realm. And throughout its lifetime, that extension happens. And, the coding profile, which identifies, is, tagarm.com2025 endorsement. CCLM100 is the profile. And since, we had a little bit difficulty in identifying the identifier, which are is the identifier of the realm. So we decided to take the initial measurements, which is unique to the realm, and that that acts as a stable identifier for the realm. So realm initial measurement acts as the realm identifier, and the measurement values are expressed, with different keys, m keys. So the measurement value map, m key for cRIM REM initial measurement is cca.realm, while the extended measurements are cca.realm. And four bank has values REM zero to REM three, and the digests are used to express the measurements. And REM personalization value is used to distinguish, realms which are instantiated with same same REM initial measurements. So you have a CCA dot RPV as the key, and the raw value is used to express detailed personalization value within the profile. So this was a brief introduction to the I think that's pretty much covering my slides. On the top page, you have the, link on those who want to loo look at this, the data tracker link is given on the, the main page. Yeah. That's all from my side. I'm happy to take the questions later down in the spare time. I believe I have completed it on time, Ned.
[00:30:43] Ned Smith: Yeah. You have Henk in the queue.
[00:30:46] Yogesh Deshpande: Okay. Henk, yes.
[00:30:49] Henk Birkholz: Yeah. Hi. This is Henk. Happy to see you. Happy to hear you. You highlighted there's only one crypto key allowed. And when I'm looking at the CDDL, that looks correct with respect to the label. But in the label, you have a set of one to more, sorry, not a set, a sequence of one to more crypto key identifiers. So, so is this all of said is this all the same but different representations, or are they actually more than one keys? And if so, what does that mean?
[00:31:22] Yogesh Deshpande: Right now, it is only one key. So we have a clear if you see the explanation in the CoRIM document and the profile document, it says only you have an array, but we only allow one one element in that. So one crypto key is assigned to one software component, which is the signer of that software component. But down the road, the plan is to increase that to one or more.
[00:31:46] Henk Birkholz: Ah, okay. So you don't want to deprecate the label, but, so thereby, it's already allowing more.
[00:31:51] Kathleen Moriarty: But
[00:31:52] Henk Birkholz: Yeah. For now, it's okay.
[00:31:53] Yogesh Deshpande: It's only one.
[00:31:54] Henk Birkholz: That makes that resolves my confusion immediately. Thank you.
[00:31:58] Ionuț Mihalcea: Welcome. Okay.
[00:32:01] Yogesh Deshpande: That's it from my side, Ned and Kathleen. Over to you.
[00:32:06] Kathleen Moriarty: Thank you, Yogesh.
[00:32:26] Ned Smith: So up next is trip trajectory. Nope. It's Tom's talk. Hang on a second. Hello to everybody. My name is Camilo Posada. So after Yogesh, we have Tom Sato, agentic attestation. Okay. Do I get to share
[00:33:16] Mark Novak: the deck here? No. I'm not speaking now. And
[00:33:24] Ned Smith: I will send you control.
[00:33:29] Tom Sato: I have site okay.
[00:33:38] Ned Smith: You ready to go?
[00:33:39] Tom Sato: Yeah. Right. Oh, I see. I see. Okay. Now I understand how to operate this thing. Thank you very much. I'd like to thank the, chairs for organizing this, interim meeting and allow me to present my drafts. This is a first for me in the RATS WG and what I would like to present is the key evidence and governance log slides I've prepared for my kernel identity and attestation drafts I have with governance audit record as a context regarding agentic attestation and audit in multi agent system. Forgive me, I'm a little bit groggy because it's 01:30 in the morning for me. Okay. So where does this fit in the RATS WG, I believe that my draft- key, is a tester and evidence profile is in scope in terms of extending the existing pattern, which extends the existing pattern of device, composite, confidential computing and then to, govern the execute, enforcement component, which which can be a operating system or something that runs the the agentic AI workload to execute and to record whatever is generated out of care. The trust chain, the hardware route to get key pair is RFC nine thousand three thirty four's own attestation and evidence terms. The continuous signed evidence we have is the same goal as the working group's own event stream subscription work. And testers' identity and composition cross principal ID is something which is also here in the right scope. The govern audit record is a downstream audit record draft I have created is the consumer of these attestation results for governance and audit purposes and the audit type architecture maps to skip submission.
[00:36:51] Ned Smith: Okay.
[00:36:51] Tom Sato: So this question, one identity question underneath all four layers which I have is, is this GEC, the governing enforcement component, who it claims to be, and, can it sign evidence? Can the signed evidence be trusted? So I wanted to answer this question. The model the RATS -nine thousand three hundred thirty four has is I think everybody is familiar where you have the attestors that are testing environment, target environment, the endorser and the verify and the reliant in party. What we what I have created the maps onto that model, I used the RATS design to design my care where the governing enforcement component would be using the hardware route and the get kernel to sign then sign the event log itself. The operator certificate endorses the GEC key and the keyer is a verifier which appraises the manifest, which goes to the guard or other GC to record or trust that decision that was made by the KIR-cono. The trust chain is what I'm describing in this slide where it starts with a hardware route. The operator route key then to the GAC attestation certificate, which generates the GAC manifest and then it gets logged into the event log entries. No signing relationship flows upwards. This is a key to the trust change mechanism I have. Excuse me. Okay. So one of the things which I was concerned about and which I designed was what do you do with the agent who is working for one gig, but it goes to another GAC to do some action. And how do you prove that it is the same agents are working in two different GECs, which would both need a audit records? How do you how do you do that? And what I've done is to create this identifier, a cross principle identifier, which is like a membership card or number which is reliable in terms of identifying whether it is your end or partners end or whatever. And this is necessary for multi agent scenario which is common these days. And I want that to be deterministic, stable, immutable and non forgeable which I decided to the draft. I wanted to also talk about the security in regard in in my draft and how I work through the security consideration. Because having a cybersecurity background, I wanted to make sure that I have a built in security consideration and mechanism that is grounded in really in the structure of my work itself. And so I review I was reviewing and trying to understand how what kind of security incident may be related to what I was building and and when I was writing this three months, I think it was three months ago prior to the IETF, I noticed that Usama had been talking about the CVE-2023-3697. And I read that, and then I went back to the CVE org and to find a more relevant CVs, which I found three of them. And and what I what I can say is that Usama's finding was very useful for me and and that this kind of help is deeply appreciated when I was writing my own draft. So whether, you know, the the working group come up with a wiki or guidelines or whatever, it is very much needed. So with that, what I there are some questions I have to the working group, but I think what I believe is that KIA fits into the next stage of the RATS working group. And and if anybody's interested in my draft, please read my draft and all the work I've done so far as a reference point for future work for people who are working on this field. Thank you.
[00:44:11] Ned Smith: Kathleen's in the queue.
[00:44:14] Kathleen Moriarty: Thank you, Tom. This was a helpful overview. The part that was missing for me is I'd like to understand how this intersects with existing work. So some on the chat are saying there's some comparison with IMA, and so understanding that would be helpful. The other thing is trustworthiness has been covered in several other active drafts. So it would be great to see a cross section to see what's being covered elsewhere or what's been proposed so that we don't introduce overlapping work. Would you be able to take that on so that we could see the the differences in in what's in drafts already? We have so many active drafts, so I know it's it's a bit much. But it would be good to see before we adopt something else what the intersection overlap is, what maybe could be incorporated into an existing draft, you know, if there could be that you just join into an existing draft and work more closely with those authors if something exists.
[00:45:21] Tom Sato: Yes. I'd be happy to work on these two points and I'll take your guidance on this and I'll mention what I've decided to do in the mailing list and approach other parties accordingly. Thank you very much.
[00:45:37] Kathleen Moriarty: Thank you.
[00:45:42] Ned Smith: Okay. Moving on. Okay. Okay. Kia is I'll be presenting this for any Okay. This is Ionuț Mihalcea.
[00:46:23] Ionuț Mihalcea: Yes. Thank you. Okay. Thank you. So, oh, I can see that the timer hasn't been reset, by the way.
[00:46:35] Ned Smith: I'll get to it. Sure.
[00:46:37] Ionuț Mihalcea: Ten minutes. Okay. So so I'm gonna present the key attestation for the entity attestation tokens. So this is work that's been actually happening quite in the background for for a while now for reasons that I'll cover shortly. But before I start, I just wanted to to talk a bit about key attestation, what what this means to try to preempt maybe some confusion. So so by key attestation, we essentially want to convey some some idea about, let's say, provenance or authenticity of a of a key and to essentially bind it to evidence that belongs to a specific platform. So so that's essentially what we're trying to cover here. So if you look at the gap that this is trying to to resolve, we have an example here of the the problem. So let's say that a malicious client wants to get the certificate for a bad private key pair per private public key pair. So this is bad in the sense that it's never stored in the key, but we want to get a certificate that presumably asserts that the key is being protected. The client can request evidence for some some exposed API and get the evidence from a t. The evidence is obviously properly signed and attest to some some correct base. And the client can then submit a CSR with the public bad key in and signed by the bad private key and appends the EAT token it got from the the EAT from the T. The CA or the verifier performed two verification steps. So it verifies first the CSI signature. That turns out to be okay. There appraises the evidence. That turns out to be okay. So then it decides, sure. I'll I'll issue the certificate for k not public. So both of these checks pass, and the reason this happens is because there's no there's no binding or no no connection between the key that, you know, presumably would have been divested or produced within the t and the key that actually signed the CSR. So there's no no linking between the two checks performed. So this is what we're we're trying to address. So where this would be obvious and where what prompted this work? So part of it was, as I've just mentioned, and, for example, CSR, that includes attestation. So if if the CA or the verifier needs to check some relationship between the key and the tester, then they'll need some sort of properties to be asserted. Similarly, in seats working group documents, we'd need some sort of binding between the evidence that is connected or bound to the TLS connection and the key that is actually used to authenticate that connection. To, like, how how will not having this these properties leads to key substitution text. So malicious entity can, as in the previous slides, just have a key outside and import it or use it externally without without it being detectable by a relying party. The second gap is that there's no no standard key protection claim being defined for for EATs. So so in EAT, you can have, for example, a CNAF claim that identifies a specific key. But this says absolutely nothing about the properties, about its life cycle, whether it was generated within within a t or what the key can be used for. Then you have RFC nine seven one one in appendix f one four, which actually illustrates the key and the key store and how this might be attested with EAT, but only only uses private use claims. So it it doesn't actually standardize any semantics for for any of the claims. And then we also have the the RATS PKIX Key Attestation document, which actually defines the sort of semantic for whether a key is extractable or never extractable, whether it's sensitive, local, and what the purpose or purposes of the key is. So it defines this, but only for for pKicks. So for other use cases or for for EAT in general, we would need similar similar properties. And this is where the draft comes in. So it introduces a new EAT claim set, which should be signed by on the testing key. It did includes a nouns verifiers for verifies flight freshness. It provides a subject public key in CNF, and then it provides a bunch of key attributes, so the ones that would reflect the same same attributes as the peak extract. So for protection properties and purpose, for example and
[00:52:17] Ned Smith: this
[00:52:17] Ionuț Mihalcea: is paired with a set of checks that that would need to be performed. So, obviously, the verifier would need to check that the claims that has been properly signed and that the the platform this is associated with is authenticated and and, you know, follows all the appraisal requirements. Then at the protocol level, you'd have a proof of possession with a tested key. So, for example, in the CSR use case that I presented earlier, that would be the signature of a CSR or NTLS when using certificate based authentication, the the signature by from the from the certified key. And the first step, which is equally important and was previously missing was the comparison between this a tested key and the key used at protocol level. So, for example, checking the the key and the CSR to the tested key or checking the end of the key from the TLS handshake certificate. So the same attack that I presented in in the first slide would now be detected because once it gets to the step where the the verifier or the relying party performs the comparison between the key that is included in the CSR and the key that is attested by the platform,
[00:53:51] Camilo Posada: by the
[00:53:51] Ionuț Mihalcea: TD, there is clearly a mismatch. So the attacker would be providing a CSR with its bad public key, but then the would would contain a public key, a good public key. So the comparison and the last step would fail. I think I've already mentioned a bit. So there's the relationship between this draft and the draft, namely that we are reusing the same the same properties, the extractable and the extractable sensitive local and the purpose oids. And in terms of consumption, we're expecting this to be used by CSR station and probably by drafts in the seat working group. So we're we're hoping to get more reviews and hoping to get more suggestions. And we're, well, hoping that this will be considered for working group adoption in the future. Thank you.
[00:54:59] Ned Smith: Within the queue. Alright. We'll move to the next one.
[00:55:18] Mark Novak: I said I requested screen share, but I'm trying to figure out what screen is it actually sharing.
[00:55:27] Ned Smith: Oh, wait. Okay. Camilo is up next.
[00:55:30] Camilo Posada: Nice. Thank you very much. Okay. I'm Camilo. I'm coauthor with Usama Sardar of Trip, trajectory based recognition of identity proof. This is an individual draft in the RATS stream, one line. Basically, these trips attest that a real continuous human is behind a digital identity. And it maps onto the Rats architecture rather than inventing its own. I'll try to keep it tight and and leave time for discussion. So slide number two.
[00:56:09] Ned Smith: I think you have control. See if it works.
[00:56:11] Camilo Posada: Yeah. Sure. So I want to start from your own figure or or our fifty nine three three four, figure one, unchanged. We have an attester that produces an evidence, a verifier, appraises it against reference values and policy, and it meets at the station results. A relying party consumes them. A trip leads on the highlighted path. It's in a tester producing evidence for a verifier. Everything else endorsers, the reference value providers, and the owners stays exactly as the RFC nine three three four defines it the same way it's defined by RF nine three three four. Trip doesn't add any role. It fits inside the architecture of RPC nine three four. Well, here it's proving a human is behind an identity. The problem proving a human is behind an identity today means biometrics, government documents, or knowledge challenges, and each has a cause. They need a party. Everyone must trust or centralize health anchor. They concentrate personal data in honeypots, and the static credentials or capture biometrics can be replayed or deepfake. Trip takes a different premise. Sustained physical movement through the real world over time as evidence of embodied existence. In RATS terms, the movement is the evidence the attested produces. So this is not proof of personhood. It's proof of embodied continuity. It doesn't tell me if there are two humans apart or enforce one account per person. It's a narrow claim. Sorry about that.
[00:58:25] Ned Smith: Where can I see that?
[00:58:51] Camilo Posada: Movement is the evidence of existence. How it works? It's in one pass. The atomic unit is a bread crumb, a compact sign claimed that the holder of a specific curve key was in a specific special cell at a given time. Bread comes chained to an append only log, a bundle to, merely sealed epochs. The epochs compose the evidence from the the verifier produces a trajectory identity token and ultimately, a proof of humanity certificate. Two things to notice. Why it receives forgery? To fake a plausible trajectory, you'd have to control GPS, Wi Fi, cellular, and inertial sensor environments across many real places over real time, not just spoof the digital infrastructure. And what it certifies is narrow, only that an identity moved through the world like a biological organism. It relay it reveals no places. So we have the same figure in but in RATS terms, the same RTC9334 figure, but you can see it mapping directly here. The tester is the trip device. The evidence the evidence are the breadcrumbs. At the very far is what we call the criticality engine. More about that later. And the attestation result is the proof of humanity certificate. The relying party is whatever consumes it. The supporting roles are untouched. Only the three the three core roles are on the two artifacts that can retrieve specific meaning. Okay? This is an active verification, fresh and noncebound results. The relying party initiates. It sends a nonce and the identity key to the verifier. The verifier issues a liveness challenge to the tester and gets a sound response. And only then, it admits the POH certificate back to the relying party. Two fields are required in every certificate, the relying party nonce and the chain head hash of issuance. We remove passive issuance entirely on the draft zero three, no certificate without a valid live response. That's what binds a result to this exchange and and stops the replay. Where does privacy comes from? Because a tested movement sounds invasive, but it it's not by construction. Raw GPS is quantized to an h three cell on the device before anything is signed or stored. Raw coordinates never leave the device. The quantization is low c and irreversible. At the full resolution, a cell is about 15,000 square meters, so there is a real ambiguity in the populated area. And the result reveals nothing locational. The proof of humanity certificates carries only statistical exponents and aggregate scores. No cell IDs, no places, no shuttle. The relying party learns that an identity moved like a living entity, never where it did. This is complementary to existing location work. We think trip seats relative to location work already in front of this group. The IT location and approximate location answers instant timing questions. Where is the device? Is x near to y? Verifology of fencing asks whether a a workload is inside a boundary for its lifetime. The proof of position endorsement asks whether the trust in human visited a device owns. What TRIP asks is a different question on a different axis. Has this identity moved like a biological entity continuously over time? So it's longitudinal. It's not instantaneous, and it's orthogonal. It means that it could exist with this. It's not replacing any of them. Appendix a has the full comparison. Okay? What are we asking? Well, first of all, we where it stands and what are if these individual draft can be positioned within the within the trip. This is not obviously an adoption call. It's early. We are working on a o five version that would be published in few days. But the three things that I value the most is if there is appetite in rats for an active continuity location at this station at all. Obviously, also, if rats is the right venue or do parts of it belonging to. And for the reviewers reviewers, particularly on the rats mapping and the freshness model, I'll name the open items myself, the topology label, the critical validation, and that would be all in the o five work. So I would love the room thoughts about this. Thank you very much.
[01:05:05] Ned Smith: Mark's on the queue. Mark, you there?
[01:05:14] Mark Novak: Yeah. No. I that's a mistake.
[01:05:20] Ned Smith: Okay. Well, I'm on the queue. So my question is around what reference values would look like. So if you're presenting evidence that is presumably corroborated with a reference value, have you thought about what a reasonable reference value might look like?
[01:05:46] Camilo Posada: Can you be a little more precise about the what do you mean by the represent in this case? Sorry.
[01:05:52] Ned Smith: So so the so the the typical Rats architecture is evidence that's presented to the verifier along with reference values. So the simple case is, hey. A testing environment collected this digest of this target environment, hand it to the verifier, then there's the vendor of that target environment presents a digest, which is the digest of that environment that they understood it to be at, say, manufacturing time. The verifier compares the two and says, yeah. They're the it's the same value. Okay.
[01:06:27] Camilo Posada: Yeah. The the point is that we are not sending wrong location at all. We're just sending the epochs or the the logs of the of the breadcrumbs within a in within Merkley tree. And that's what the verifier is attesting from the device. The relying party is receiving only the confirmation that this chain has not been broken and that there's a human identity behind this this attestation. Now what we are looking at is that we have what what is called the criticality engine, which is the the one that it's basically giving us the different elements for the relying party for the tester to issue the certificate. And these are based on on three signals specifically, which are defining the draft, which is the the spectral exponent from the displacement series. Basically, what we have is movement within time space has a physical evidence that comes from devices and can be defined within a different specific call specifical threshold. Okay? So the the certificate is carrying only the exponent of this course plus the two required freshest fields, the the ones and then chain head hash, which is the one that the relying party is receiving.
[01:08:07] Ned Smith: Okay. Maybe I don't fully grab what how how the verifier knows that the evidence is legitimate, not fakeable, not that it has actually is indication of of the human presence. I'm expecting that there would be something that you would have to compare it against as the reference.
[01:08:32] Camilo Posada: Well, sure. That criticality engine Okay. Yeah. Yeah. The criticality engine is comparing against against a statistical statistical elements that are defined by by the the frequency and the displacement of breadcrumbs in devices. And this is data collected and already physically approved. What we have in in devices that collect breadcrumbs from humans within different intervals. They could be in the case that we have we are using for the draft, we have defined intervals of fifteen minutes, but they could be obviously defined by the implementation with different depending on the case study, they can be defined with different intervals. The the group of the epoch of these intervals of these breadcrumbs is the one that it's received by the by the by the very far, and it's sent by the device itself. So the the device is pushing this this information to the tester. The tester is with the with the critical engineers verifying that this specific epoch of of redcoms rely is is within the threshold of the of the human movement, which is obviously different from the one that could be done by a bot or could be done by a drone or any other physical device that it's emitting any position within geolocation position. Now the the data that is sent by the tester to the to the very far is it's one ties within an h three cell that it's not exposing the specific longitude and latitude of the location of the device. It's just giving the certification that one retcon was collected within that specific h three cell. That it has a definition, obviously, that can be equally say change, it could be more or less refined, it could be h three cells have different resolutions. So in our case, we are adopting a resolution of 15,000 square meters, which is a pretty big h three cell. But depending the use case, h three cells could be more or less defined by the case. That's what the attester is collecting, and that's what it's sending to the relying party.
[01:11:10] Ned Smith: Okay. Let's work. We're at time, but we'll take a couple more minutes for the queue. Henk?
[01:11:17] Henk Birkholz: Yeah. Hi. This is Henk. So let me summarize this. You are using Uber's h three hex grid layout to check, I wanna say, mobile personal devices, if those are carried and moved by humans. Is that correct?
[01:11:38] Camilo Posada: Correct.
[01:11:40] Henk Birkholz: Okay. I would write this in the first sentence because it took me some way to unearth that one sentence from from text and presentation, to be honest. The presentation was the text. Also, I'm not entirely sure how I feel about that. It's just abstraction of the of the HD. Also, the second item is, you're using the term epoch, which I think translates to time period, some period of time, or is there more to it? We really establish a zero, and why is that if you
[01:12:15] Camilo Posada: The epoch is is the the concept of of specific point in time, okay, which is basically okay. In our case, that specific lapse of log or or period of time is the one that collects the breadcrumbs in the in the
[01:12:37] Camilo Birkholz: Okay. Does it make sense does it make sense for you to just use u two UTC instead of creating a new epoch?
[01:12:43] Camilo Posada: Sorry. I didn't hear you very well, Henk.
[01:12:46] Mark Novak: Could you
[01:12:46] Henk Gunn: just what? Make sense to
[01:12:47] Henk Birkholz: you to reuse the existing time scale, obviously, like something that epoch instead of creating a new epoch for that?
[01:12:58] Camilo Posada: Well, each, you know, each it's a it's an event, and each one of these has a creates an epoch for
[01:13:04] Yogesh Deshpande: How do
[01:13:04] Henk Birkholz: you record the event time?
[01:13:06] Ionuț Mihalcea: Excuse me?
[01:13:08] Henk Birkholz: How do you record the event time? In which format? Well, in which which time scale? How is it recorded?
[01:13:16] Camilo Posada: Well, it's caught by the device, by the GPS of the device. Okay? And
[01:13:19] Camilo Posada: That it is UTC.
[01:13:20] Henk Birkholz: The device has a g p GPS is maybe a lower positioning timescale. But but but my my point is important is leading here because you're just describing a time frame, and I'm I'm shutting up. Time is of the essence also. Yeah.
[01:13:35] Ned Smith: I wanna give give Yogesh a minute first question.
[01:13:39] Yogesh Deshpande: Yeah. I think And we can
[01:13:40] Ned Smith: we can continue the discussion on the list as well.
[01:13:42] Yogesh Deshpande: Yeah. I think let's continue on the discussion on I I don't want to hang on too much. I think, the model seems more like, a policy which, applies to SCITT where you would have a predefined route spread into a and then compare it against the log transparency log, which records the moment of a human identity and an associated bound g GNSS claim. That's what I understood from the top level of it. It doesn't very much fit like a rats kind of architecture, but that's my personal view. Yeah.
[01:14:19] Ned Smith: Okay. Thanks, Camilo.
[01:14:23] Camilo Posada: Thank you.
[01:14:38] Mark Novak: Alright. My turn. So we're presenting the work of the trustworthy workload identity SIG at the confidential computing consortium, and this is to solve a very important problem in unblocking the deployment of confidential computing. So what we have today is we have credential acquisition systems. So we have SPIFI SPIRE. We have ACME v two and probably others that I'm not mentioning right now. None of them understand remote attestation. None of them understand evidence or the fact that there could be freshness. The second problem is that the relying parties overwhelmingly by an enormous margin. They, again, do not understand remote attestation, do not understand attestation result, and many of them will not understand attestation result. They're just not upgradable. So to have successful confidential computing, we have to have adoption. And to have adoption is we need to hide the fact that remoteization is happening from most parties in this game. So the TACRA is the proposed solution to this. We'll go over this real quick. So these are the requirements. I'm gonna go through them one by one. So we need to be able to enroll new credentials and as well as retrieve existing credentials. So this latter is used for replica workloads, so horizontal scale outs when you have multiple identical function identical workloads, but we do not have the facility to generate and stamp keys at the speed where containers may be coming up and down. Then we need to be able to support credential formats that currently exist as well as future. So, of course, proof of possession credentials, various forms of certificates, and also begrudgingly, again, because we need to support the world out there, bearer tokens of various kind. Now, whatever you put into your workload to make it work in this world should not be too much. So we need to limit the transboundary expansion and we need to support current as well as future credential acquisition mechanisms. So EST, SPIRE, and whatever else comes later. Right? So credential requirement number five, goal number five is we could have, you know, CAS sorry. SPIFI used to fetch some JSON web token, but EST used to fetch some certificates. So there should not be a preclusion against using yeah. Or limiting one to just one one creation acquisition mechanism. Now the requirement six is whether background check is used or rats or a passport is used to the tester that actually doesn't make much of a difference, turns out. And we need to support existing and future rat certifiers, credential authorities, secret faults, again, transparently to the tester. And because some things run on things like Nitro where there is no network stack, you cannot assume that the tester has independent network access or storage access for that matter. Right? And then you need to be able to do it on top of TTX and SEV and RMCCA and whatever. And, finally, the credential authority, Sorry. The credential acquisition system, your Spire agent, your Spire server, EST client server, we would like to move them outside of the trust boundary so they can relay messages back and forth, but we don't want them to see the contents. Now it is not a goal to leave these credential acquisition mechanisms intact because left intact like Spiffy workload API cannot be made to understand remote attestation. And so we're talking about extending these protocols, and we have another draft in the works that shows how to do it for EST, and that's a blueprint for how all of them can be done. Alright. So it's a it's a very ambitious set of requirements, and in the draft, we show that each one of them is satisfied by what follows. So this is the picture. And in the following slides, I'm going to take it's a very, very busy picture, of course. I'm gonna take it line by line. So first of all, we have inside a workload, place one thing, and that could be a library or it can be a sidecar like Envoy, but we call this thing the credential acquisition interface or CAI, and it exposes one API. It's called acquired credentials. So when you say acquired credential, you say who I want to authenticate to and what credential type I want. So I maybe say I want to go to my payroll database, and I want to get a JSON web token for it. And that is intentionally, you know, all the information that is needed and is provided to the tester out of band. Like, the the tester simply knows what it's asking for. Okay? So that's the that's the simple thing. You write you put the screen share acquisition interface alongside your workload like you would would with a nonvoice sidecar. You call this one API. It takes care of everything. So underneath, there is the credential acquisition API, and this is the you know, hopefully, we'll implement it once, and it's composed of three calls. There's initiate followed by either retrieve or enroll. So when you call initiate, you say, again, this is the target I want to authenticate to. This is a credential type. It'll come back with a handle which is can may contain freshness. It will contain what cipher suites are necessary and whatever other information you need to do the following two calls. Retrieve and enroll, you only call one of them because there are two modes. You can retrieve a preexisting credential and, again, for initiate, it's going to come back and say, this this is what you can do. Like, you you call it free next or you call it roll next, and you supply this handle. You supply the evidence and a public portion of an encryption key. And in the evidence, of course, you include the binding with the key. Similarly for enroll, this is where you create a CSR and you put data in evidence, and it follows a different path where it will return the certificate to you, but you're the holder of the private sign. Alright. So the next part here is the platform plug in, and the platform plug in abstracts away the details of your platform application binary interface. So this one gets implemented separately for TDX, separately for SCV, and whatever other platform you're be running on. But ultimately, conceptually, it gives you just two APIs. Generate me some key with some of a certain type, with certain key strength parameters that will be asking the platform RNG to give you some key material. And the final one is the generate evidence where, again, you'll specify what you wanna place in evidence, and it will give you that. Alright. So then we're going over to your credential acquisition system. So that could be Spire or EST or anything else. And to the protocol that is used for credential acquisition, we add the following three API. And, again, they do not exist today. They're initiate, retrieve, and enroll that basically follow the same thing. For that, we put plug ins inside both of your credential acquisition clients, your Spire agent, and your credential acquisition server, which is the Spire server and whatnot. And the it's the server's job to go talk to the verifier, to talk to the secret vault, to talk to the credential authority, and it to basically orchestrate passport versus background check, etcetera. Again, so we are down to just two minutes. Finally, and this is the goal, your relying party here is the existing thing that's out there today. It is completely zero blast radius, so it's not affected at all. And that is because it whatever it expected you to give it before for authentication from the same issuer and with the same exact format, you the tester present that with no change whatsoever. It's just an equivalent function, equivalent credential. It looks the same. It's just been obtained using remote attestation instead of just being handed to the workload in Playtech. Finally, the references. So this is a work of the trustworthy workload identity SIG at the consortium, the consortium. So we have the charter. We have the requirements. We have the definitions. All of these are pretty generic. This informational draft, if you wanna do pull requests, is this. Then we have another draft that's coming up, which I'm giving you the GitHub link right now, but we're showing how to do it with EST. I'm hoping to submit that this week. What is gonna go to the LAMPS, same place that does CSR test. And we already have one POC implementation with HashiCorp, which, again, you can go to these links and look at these branches. So, now we're starting to get some support for this. Alright. I have a minute left. Any questions?
[01:24:04] Ned Smith: Looks like you're in the queue. Hi. Henk is in the queue.
[01:24:09] Mark Novak: Okay.
[01:24:11] Henk Birkholz: Yeah. Hi. This is Henk. Just a comment, another really question. So I think this really, for the first time, addresses, the obstruction of the RATS architecture to generic relying parties. And I think also that EST is only an exemplary building block. Right? So we need to have a a general document that specifies the, I wanna say, information that means for all the protocols here, the acquisition protocols. Is that correct?
[01:24:42] Mark Novak: Yes. That's this is what the TACRA architecture does. It basically says, these are the messages. Render them in whatever protocol you got. You can render them as EST. You can render them as Spire, but it's a three leg exchange that supports all the currently known variants. And so long as your protocol supports it through these plug ins, you should be able to go and do it.
[01:25:03] Henk Birkholz: Yeah. Okay. Thank you.
[01:25:07] Ned Smith: I'll I'll keep we'll continue to answer questions. Usama?
[01:25:13] Muhammad Usama Sardar: Yeah. Usama to you, Kristen. I think that the kind of the clarification I need is that, is this supposed to work with the confidential computing? Is that within scope, or is that
[01:25:25] Mark Novak: out of scope?
[01:25:26] Muhammad Usama Sardar: If that is in scope, then the problem is that how are you going to how are you going to provide the identity without having the cloud provider in the trusted computing base? And how is that going to be? Like, I think that is the CoServ, if I understand correctly, in your in your architecture, and it's not clear to me how you're going to do that in this specific proposal even if even if you're
[01:25:52] Ionuț Mihalcea: So You
[01:25:54] Mark Novak: today, your provider your your cloud service provider comes in two places. They usually operate the hardware on which you run your workload, and this is where you need to work with them on the understanding that they will manage the hardware correctly. Otherwise, don't use that provider. And it comes in operating services on the back end, such as credential authority, secret vault, draft verifier. So, again, you can operate your own, or you can trust your provider to use that. Under this architecture, the client and the server of the credential acquisition system, so, again, your Spire agent, your Spire server, etcetera, they are conduits. So they are not they're safeguards in place against them getting access to credentials, and they are treated effectively as routers. Their job is to render messages in a particular protocol format and to deliver them.
[01:26:48] Muhammad Usama Sardar: I don't think you answered my specific question. I was asking how is the identity provided without having the cloud provider in the TCP?
[01:26:57] Mark Novak: Identity of what?
[01:26:59] Muhammad Usama Sardar: Identity of that confidential computing workload. You said that confidential computing is in space is in is in scope, and that's what I'm trying to understand.
[01:27:11] Mark Novak: So identity is a combination of two things. It's the identity of your hardware for which you have to trust that your hardware is properly managed by your provider, which, again, you can check by at at the verifier level, whatever evidence it generates, plus identity of the workload, which is the measurements, the, you know, whatever goes in the quote about the workload itself. So this is no different. There is no difference between this and any other way you're doing remote application.
[01:27:38] Muhammad Usama Sardar: I don't think that's correct.
[01:27:39] Mark Novak: This introduces no failure mode. This introduces no new types of evidence. This is simply a way of relaying information through, now untrusted credential acquisition system.
[01:27:49] Muhammad Usama Sardar: So the problem I'm highlighting is kind of, I think, still kind of orthogonal to what you are saying. So you said that there are two identities, one of the hardware, one of the workload. There is at least a third identity, which is of the host that if you have the PKI. If you don't have the PKI, my question will be what prevents that relay attacks. But within your spectrum that you are mentioning, the hardware identity, as far as I know, currently, there is no way to actually check that hardware identity. So none of the cloud providers, to my knowledge, today are providing you which servers are in their possession. And this is like you will have that hardware identity, whatever that means to you, like PA ID from Intel or, let's say, chip ID or hardware ID from AMD. And similarly, like like, platform instance identified from ARM CCK. But to the best of my knowledge, there is no way a verifier can have some reference value or something with which I mean, something is coming from the evidence, and the other thing is with which you will compare it. The evidence may contain that. That's fine. But what is the other thing with which you will compare that? What is that subset of the machines that, let's say, Google or
[01:29:11] Mark Novak: Usama, nothing you're saying is has any relevance specifically to this draft. Okay. So I if you want to discuss this further, come join our SIG meetings.
[01:29:23] Muhammad Usama Sardar: Sure. Thanks.
[01:29:25] Ned Smith: Okay. I got does it for the queue. Thank you, Mark.
[01:29:30] Henk Birkholz: Mhmm.
[01:29:30] Ned Smith: So our next topic, we're gonna take a rain check on it. So I think that's that wraps it up for the planned talks. We do have some open mic time for anything else. And there were some discussion on the list about having to do with with trying to find it here. Michael Richardson had a thread going here. So
[01:30:03] Kathleen Moriarty: do
[01:30:03] Ned Smith: do you
[01:30:03] Kathleen Moriarty: want to take
[01:30:04] Ionuț Mihalcea: that over?
[01:30:04] Yogesh Deshpande: It was up about our composite to test our draft, which we recently moved to the wiki. So we wanted to check what is the best way of expressing that. That was the main main point here.
[01:30:17] Kathleen Moriarty: Yeah. So we can set up a poll while we have the other discussion pieces. So, Ned, I I can help with that. I'm just gonna make a comment quickly on Mark's draft. So thank you for submitting that, Mark. Sorry. I was in the middle of something else to not get on, quick enough. And, this looks interesting. There will be obviously a lot of coordination points. So I read it this morning. I need to digest it myself. I'm sure others do as well. We you know, we'll have to figure out is rats the right place for it? Is somewhere else the right place for it? It might be rats. And then just make sure that we have the coordination in place with the area directors if it moves forward in rats.
[01:31:04] Mark Novak: Right. So I I cannot think of a better place than rats. At the same time, explicitly, the goal was to stay 100%, without exceptions, within the existing RATS architecture.
[01:31:17] Kathleen Moriarty: Okay. Alright. Great. It's just so many coordinating points. We'll wanna make sure that others throughout the IETf who work on those coordinating points are aware and can participate.
[01:31:29] Mark Novak: Inside and outside, because Spire is not within IETf. But, again, we'll have to work with them as well. AWS is not with Ionu. Like, they just don't don't use confidential computing. We'll have to work with them as well. But, ultimately look. The reason I believe it's in rats or has to be in rats is because this is what puts this, I believe, puts remote attestation as a mainstream technology.
[01:31:53] Kathleen Moriarty: Yes. Yeah. So we'll have to have larger discussion. I think some of the Whimsy folks and some other people and Whimsy, they they're very active in OAuth. They were also active with the the Jose and Jose work. Right? So let's have more discussion on this. I appreciate the work, and it is something that has been brought up. And so you're putting something into paper, which is great. Thank you.
[01:32:25] Mark Novak: Right.
[01:32:34] Ned Smith: Lachlan?
[01:32:37] Lachlan Gunn: Hi. Yeah. Sorry. I I also had a had a question for the the previous speaker that I kinda put my hand down when the time was running short. So I kind of have a question in in terms of this as kind of an architecture versus a protocol draft. In some sense, it to me, it feels like it's kind of almost asomorphic to to reps to the reps' architecture in general in the sense that, you know, normally, look at, okay, you've got your attester, you've got your verifier, and you've got things like EAT and e r EAR that are kind of dealing with the attestation tokens, attestation results, and and so on. And kind of looking at that architecture, it kinda feels like this fits in really nicely, but in the sense that now it's kind of a let's say, a special kind of attestation result that just happens to look, you know, exactly like No.
[01:33:32] Mark Novak: You're incorrect. You're incorrect. Rats architecture, while correct in, you know, pretty much every way I can think of, has made one grave error, and that's the naming error. It called the recipient of attestation results the relying party, and it keeps confusing the hell out of everyone. So they look at this and they think that's I have to take my payroll database and I have to teach it about attestation results. And that is what the the sort of fly in the ointment is. So what TACRA basically says, it says, we're leaving RATS relying party to be the RATS relying party, which in this case is the is the secret vault or your credential authority. And we are making a specific addition. We're calling it the RATS underwear relying party, which is outside of RATS, but that's the thing the tester wants to talk to. That thing will not understand attestation results, will not have appraisal policy for attestation results. It's old. It's dumb. It's static, and it is what makes the world go around today. So we need to work with it.
[01:34:45] Henk Birkholz: Okay? Okay. Cool. Yep.
[01:34:53] Ned Smith: Alright. So we're doing a show of hands.
[01:35:00] Kathleen Moriarty: No. I messed it up. So we're not doing one yet unless you have one ready, Ned. I'm only getting yes, no, and no opinion as opposed to I'm trying to figure out how do I do four choices. So I canceled the
[01:35:14] Ionuț Mihalcea: last one.
[01:35:14] Ned Smith: You wanna scrub this one? Oh, okay.
[01:35:17] Kathleen Moriarty: I think I already did.
[01:35:18] Ned Smith: I
[01:35:23] Yogesh Deshpande: think before you before you show off hands, Kathleen and Ned, I want to request to set the context properly so that people understand what exactly are we asking for.
[01:35:34] Kathleen Moriarty: Yes. Yes. Yes. I hadn't I thought by hitting enter, I thought I was only putting a title on it, and I thought I'd have the ability to edit the poll. And so I agree. Do you wanna try to set context while Ned and I try to figure out how to set up the poll in the way that was requested? Otherwise, we're gonna have to come up with yes, no, no opinion series.
[01:35:55] Ned Smith: Sure.
[01:35:56] Kathleen Moriarty: Thank you.
[01:35:57] Yogesh Deshpande: Yeah. I will set the context. I I I want to kind of, want to say that as part of the RATS working group design meetings, we started work on composite attestation. And as part of that activity, we we started to say that what are what is the kind of, attestors we are talking about here? What comprises of, composite attestation? What do we mean? Do we mean layered evidence, composite device, which has multiple components? What are the taxonomy? What are the different types of devices, classes of devices? So we started preparing a draft, and we started working on the draft. But of late, because of our lack of knowledge about the different types of attesters and also we, some some of our team members believed that this could always be evolving. So some of them thought that it is best to put that in a wiki and refer it from other drafts like maybe multi verifier, which requires different type of verification based on different types of attesters. So the question here is the type of attesters, the variety of attesters, is it should be documented as a draft whichever team group should adopt and then make it as a informational RFC, or it should remain just as a wiki? That's my view, but I would love to add if Michael thinks there is something more to add. And I'm happy to share the link of the existing work so far before it became a wiki. So o four Please
[01:37:26] Mark Novak: do. Yeah.
[01:37:28] Kathleen Moriarty: Yeah. And I tried so I'm changing what yes means, what no means, and no opinion. If the working group agrees, we can use the poll I just started. Otherwise, we can figure out how we change it. Maybe Ned knows more on how to the polling tool than me and can do a better job. But
[01:37:50] Ned Smith: I just think we take them one by one. I want I wanna keep it as a wiki. Yes. No. Then then go to the next one.
[01:38:01] Kathleen Moriarty: Okay. Take a look at what I did, Ned. And if you wanna change it, feel free to go ahead. I just changed what yes means, what no means, and what no opinion means to get it done quicker.
[01:38:24] Ned Smith: Let's try it.
[01:38:25] Kathleen Moriarty: But if people don't like it, we can change. Nope. No big deal. For what it's
[01:38:28] Henk Birkholz: worth, I think Kathleen's description of what yes, no, or no opinion means was straightforward and okay. But if you wanna change it again, why not?
[01:39:07] Kathleen Moriarty: Alright. So we have nine
[01:39:09] Ned Smith: participation. Yeah.
[01:39:10] Kathleen Moriarty: Yeah. Nine out of 15. And I didn't as a chair, I didn't put in a vote.
[01:39:18] Ned Smith: Neither did I.
[01:39:20] Kathleen Moriarty: Yeah. So we may be, yeah, 10. So there's only three other people. So we might be done then. Oh, okay. Yeah. 11. So far, the wiki is the most preferred. So those with the no or no opinion, if it's something strong and that it's objectionable to use the wiki, we could take a couple minutes to hear the reasoning behind that to see if it changes the outcome.
[01:40:12] Ned Smith: Usama, it's on the queue.
[01:40:16] Kathleen Moriarty: Go ahead, Usama. Thanks.
[01:40:19] Muhammad Usama Sardar: Basically, I I voted for you. The reasoning for that is basically that this draft, I supported your set option as well. When it was brought up, I attended the meetings for this specific draft. I think this was progressing well. We were kind of understanding what the thing is, what what is it that what is the composition of the tester that we call a tester and going into what kind of where does the non score and all these kind of things. I I really like the way it was progressing, and I would have liked it not to be in the wiki, but as a draft, which was increasing our understanding, our intuition, and getting us closer to what we think of what an attester is and putting all that complexity into one big box and trying to go into that. And when we have, like, from a practical perspective, if you look at that, basically, it's adding a lot of practical insights, meaning that you have a CPU. You have now a GPU. You have a this kind of an attester, which is also from our perspective. If you look that's a platform attester, and then there is a, how is it called, the realm attester in ARMCC language. So there are two attesters which are at the same time being attested. And getting to know where these things are happening and all that is all practical information, and I really like the way it was progressing. I would have liked to have it, like, being discussed as a, like, work in progress ID rather than a Wiki.
[01:41:56] Kathleen Moriarty: So some of this is yeah. So this is just for the taxonomy. Do you realize that? Just to make sure.
[01:42:05] Muhammad Usama Sardar: Yeah. I mean, I'm still talking about the taxonomy. Sure. I understand that. So the taxonomy meaning that a tester's taxonomy to me, it meant that the draft was actually describing what is the kind of the possible attester composition it would have, and all my comments were exactly on that. I don't see what the confusion is.
[01:42:26] Kathleen Moriarty: Okay. Just making sure you were clear on the question. Are there any of the other, people in favor of a draft, either normative or informative, that, want to say why, or if or if they're okay with the, majority who were interested to see this, just go to a wiki for now.
[01:42:54] Yogesh Deshpande: Kathleen, I just had a question on the clarification, which might help me understand. How is the wikis maintained in Ritz or in the ITF in general? So that how is the maintenance happen? Do can they rot, or can they go in a corner and nobody watches it or views it? How do you address those questions?
[01:43:14] Kathleen Moriarty: It's working group specific. So in this instance, it would be the design team would maintain that particular text, and we could do something with it at a later date. Right? So it might be that they want something more flexible for now, hence, the use of a wiki before it gets more formal. And for instant, so it it depends. And so in the case of the security considerations piece, the way a wiki is used is that the working group decides on set considerations, which would be similar of deciding on set definitions. Right? And that the working group would refer back to that guidance before publishing to make sure things are in alignment. And so you do use it as a gating process. The shepherds would look to use this. Authors would look to use it. And before something leaves the working group, it would be a point of reference if we make that part of our procedures. Okay. Does that help you, Yogesh?
[01:44:22] Yogesh Deshpande: Yeah. Yeah. I think Great. I after your answer, I feel that we can start with Wiki once it's mature, stabilizes, and see that no further updates are happening in the ecosystem, then we can consider putting it back as a informational RFC. Okay. Great.
[01:44:37] Mark Novak: Yeah. Yeah. Thank you.
[01:44:39] Kathleen Moriarty: Thank you.
[01:44:44] Ned Smith: Okay. So we have a few minutes for open mic time. Are there any other topics? Alright. Sounds like there aren't. So that concludes our meeting. Thanks everyone for presenting. And for those who are taking notes, thank you for doing that.
[01:45:10] Yogesh Deshpande: Thank you, everyone. Thank
[01:45:13] Camilo Posada: you. Hopefully, do you have any
[01:45:14] Kathleen Moriarty: Thank you. Final words. For the newcomers bringing work in.
[01:45:18] Ned Smith: Okay. Fantastic. Thanks, everybody.
[01:45:25] Camilo Posada: Thank you.