Session Date/Time: 22 Jul 2026 07:00
[00:00:05] Ned Smith: Yeah. It's typically just decision. It's it's just some for whatever reason, if someone can't their their, you know, their audio or video isn't working and they wanna make a comment, we need to relay that through someone who's here in person, but I don't think we get too much of that.
[00:00:35] Mike Ounsworth: Okay. Should we start?
[00:00:37] Kathleen Moriarty: Yep. Yep.
[00:00:38] Ned Smith: Alright. We're gonna get started. Welcome to the Rats session.
[00:00:43] Kathleen Moriarty: Good morning.
[00:00:43] Michael Richardson: Good morning.
[00:00:44] Ned Smith: Good Morning.
[00:00:45] Kathleen Moriarty: Morning, Hank.
[00:00:47] Yogesh Deshpande: Thank you, sir. So we can start.
[00:00:49] Ned Smith: Yeah. We can start now.
[00:00:50] Michael Richardson: I was just trying to get him to be quiet.
[00:00:55] Ned Smith: Alright. So I'm gonna click through the chair slides. So the you've all seen this. This is the note well describes the the ways that you can contribute in the ITF. So please, you know, I'm not gonna go through it in detail. I think it's picking up. Can you guys hear me? It seems like it's, like, really loud.
[00:01:13] Yogesh Deshpande: Need to
[00:01:13] Yaron Sheffer: get close.
[00:01:14] Ned Smith: Get closer. Yeah.
[00:01:16] Kathleen Moriarty: And remote people, can you hear okay?
[00:01:20] Ned Smith: Alright.
[00:01:21] Kentaro Takahashi: I'm fine.
[00:01:23] Ned Smith: Just a review of the code of conduct. So, you know, extend respect and courtesy to your colleagues. Try to make our conversations impersonal, focus on the content, not on the person. We're and just a reminder, we're we're working for the better good of the Internet, so put keep that in mind as you're you're, you know, making your contribution, and we look forward to to everyone contributing. We have our notes takers, so thank you very much. Links to the materials, if you don't have them, they're on the chair slides, and then we can jump into our agenda. So but before we do that, we'll we'll take a minute to pause and see if there's an agenda bash topic. Otherwise, we're gonna
[00:02:14] Thomas Fossati: go with what we have here. I will note that in the on the list, there was a bit of discussion around, hey. There's not enough time this time around for all of the presentations that
[00:02:25] Ned Smith: that were requested. And so we've already decided to do a virtual interim following this meeting, and there's also a a poll that's been that's been open to collect your feedback in terms of when would would work best for folks. So please follow-up this meeting with participation on the poll so we know when to have the next meeting. Okay. So agenda topics. If not, we will jump into the agenda. And first up is Mike. He kicks evidence encoding. Sure. And I can help share.
[00:03:25] Thomas Fossati: Okay.
[00:03:28] Mike Ounsworth: The real mic is slides. That's a monitor. I don't I don't have a monitor. That's fun. Could I Oh. Be able to see that?
[00:03:43] Paul Howard: This is this is
[00:03:44] Kathleen Moriarty: your monitoring.
[00:03:45] Ned Smith: Well, there's a monitor. It's probably supposed to be that one over there. I
[00:03:47] Mike Ounsworth: don't Okay. That's Hi. We're we've done this before. This is this is draft has changed names a few times. It was pkix evidence. It was HSM's evidence. It was pkix's 11 evidence. It's key key evidence or key at this this draft's. It's the same thing all the way through. We're now calling it evidence encoding for hardware security modules, which we think is the right balance of describing what it does without calling it pkix, which no one knows what it is. So, again, this is this is the document that is intended to say, does the clicker have permissions? I'm gonna have to give the clicker permissions. This is the document that's intended to say if you have a private key in a, like, big HSM and you wanna attest to the the fact that the private key is in hardware and its p 11 properties. It is it is generated in the HSM, and it is marked non extractable and marked sensitive and all the other p 11 properties, and you wanna bundle that up together with the properties of the platform. It's in the hardware model, hardware serial, and put that into a proper attestation. That's what this is providing a data format for and some semantics, but mostly it's just data format. Can I click? I can click. Alright. So we're gonna go through the just just to remind the group of the general structure of the thing we're proposing, which has not changed in any substantial way since last time, and then we'll quickly go through an overview of the update since last time. We have good running code story at this point, and then we're basically basically asking for working group last call at this point. So the structure, we've designed this thing to feel very similar to stuff in pkix. It feels very similar to the structure of x five zero nine or to CMS in that it is a DARE encoded to be signed, TBS object. It's a TBS evidence with claims that are structured that all feel very familiar to anything that feels like an x five zero nine extension or a CMS object. We've bandied over words quite a bit. We're now calling the the core object an element. So this is composed of elements such as a, platform element or a key element. So so your your evidence will have one platform element. That is the piece of hardware it's sitting on. It can have more than one key element. You could be describing you could have multiple TLS keys, and you wanna describe them all in one attestation. So you can load up multiple key elements. And then there's always a transaction element, which has a knots and a time stamp and other sort of record keeping junk. And that's the general structure. It's just I mean, it would map to to JSON or CBOR in a fairly straightforward way if someone was so inclined to do so. These are just type value pairs where the type is an and the value is is some string or integer type. This is designed to be fully extensible. Anyone can assign their own off their own arcs. You can add your own elements, and you can add your own claim types. So if you wanted to if you decided that the the way we've described platform doesn't meet your the needs of your hardware, you can fully free to to define your own top level element that better describes your your product. So this document is basically it's the structure. It's the general structure here, and then it's a bunch of sort of default claims, defining a bunch of default claims. But, again, fully extensible. You're allowed to ignore the claims we defined into your own. Next. Click. So since last time, we've updated the ASN one module. We had a bit of a back and forth with Russ and Mike Saint Johns about 1988 versus 2002 syntax for ASN one, specifically around the word any, which is now gone. The word any is no longer in there, and the ASN one module is much longer and more complicated. If you don't like ASN one, it's gotten worse. I'm sorry. As a consequence, we now had to rewrite the ASN one module, and the document is is changed. And then we had to redo our our reference implementation because the the even though ASN one is a presentation language, the change we had to make did affect the wire format. So it's not backwards compatible with the previous version of the draft. It's as close as we could possibly get it, but it is slightly different wire encoding. So huge thanks to Mike St. John and Russ for helping us move that forward. Extended key usage. So this has bounced a few times. So we're we're this changed to an x five zero nine cert. So the evidence is signed by an x five zero nine cert, which is the AK cert. And we bounced back and forth a few times about how do you identify that this is an AK cert? The obvious thing is extended key usage, but there if we couldn't find a good already defined EKU for for AK key, there are some in TCG, but they're specific to the TCG data formats. And so we didn't wanna start blurring, steal something from TCG. And now that you've got a cert that can find multiple formats and it gets ambiguous, so we certainly need our own EKU. We took this to LAMPS in Montreal, and we were told LAMPS isn't the right place for this. You don't need a whole LAMPS document just to define one OID. So now we've buried it back in this document. So now this document is gonna register an EKU under the LAMPS arc, and Rust is fine with that. And
[00:09:05] Ned Smith: So
[00:09:05] Mike Ounsworth: this has been sorted out, hopefully, for the last time. The sample code and reference implementations and the samples at the bottom of the draft now properly have a cert that contains this OID that's defined in this document. Yeah. We renamed entity to element. So previously, we'd called things entities, platform entity. The word entity got confusing. We did a big search for more words. We tried subject. We tried component. We tried members. It's been a big exercise in pipe shedding. We settled on element. Hopefully, element is fine, and we don't have to have this anymore. Yeah. Which ended up being I'll just say that was, like, a large diff. So if you do a version to version diff, we had to change, like, every sentence because this word shows up an obnoxious number of times in the document, but it's a fairly ins insubstantial change. Drop user mods. So we've had a similar debate that I believe has happened in EAT, which is like, what is a user mod? And especially in HSMs, all the big HSMs have a way to load third party code, trusted executions or and Shield calls them code safe environments. There's always some way to say, like, here's an application that I built, and I'd like to load it and have it run inside the hardware boundary of my HSM, maybe with some special privilege access to the keys or something. All HSMs have a way to do this. Seems incredibly relevant. If you're saying, I please attest this key you're holding, the fact that there's some code that the HSM vendor didn't write that has privilege access to that code seems like a thing you'd want to attest to. But it turns out there's, like, no good way to describe this in a vendor agnostic way. Every vendor is gonna have their own, like, way of describing or or even of handling third party code and the level to which it's sandboxed, and can you describe the sandboxing? It's all gets super proprietary. So we've given up. We are not gonna attempt to do this. We have just taken it out of the draft. We figure even if we had a user mod, like, immediately, the data in it would need to be vendor proprietary anyway. So what's what's the point? So we're just gonna take it out. Makes the whole thing easier. And we did a bunch of other stuff. GitHub issues, open, closed, feedback, commas, nets, better references. We do have an open issue. This will come up later. Signature identifier. Carl Wallace pointed out we're defining an ASN one structure called signature identifier, and there's already a thing somewhere else in the world of pkix in some ASN one mod, in some other RFC that already defines a struct by that name. And so if you're Carl and you have ASN one mods for everything ever imagined all loaded into the same software at the same time, there's a name collision. That's So one open issue we haven't solved yet is do we rename our thing? Probably, we should. Running code. We've done some good hackathon work. Hannes, I'm looking at you. And, JP, I'm looking at you. We did some good work at what the January, which we continued this time. So we now have a reference implementation that lives in the rats repo. So that's that's the official IETf rats working group. GitHub repo, this is the same repo where the draft source lives. We now have a full reference implementation in Python. And so we structured this so the ref the Python generates the samples that go into the appendix of the draft. So we just do Python run, and then we do markdown make, and it just sucks the thing in. And it's beautiful. And if you wanna see where the samples came from, the Python is right there. And this time, we also added a verifier. So you can see at the bottom there, there's a nice little command line dash dash validate, and you provided the evidence PEM, and you provided the cert. And it says evidence validation successful, and then it pretty prints it for you. So that's cool. We think that's helpful for having running code. This is the hackathon, so we didn't fully get it. Turns out Python can't validate search chains unless they're TLS certs. So I spent most of my hackathon trying to figure how to get Python to validate a cert that wasn't a TLS cert, and I failed. So that doesn't do it yet. But, anyway, yeah, this is here. So if other people wanna try making evidence and get it to be validated by the recommendation, it does that. Also, CryptoFore is halfway through their own productionized implementation, which, of course, they're gonna be testing against the reference implementation. So we've got, you know, a robust reference implementation, and we have one vendor who's halfway through implementation. So I think we can say pretty resoundingly at this point draft is implementable. Neither the hackathon team nor cooked before it has hit any, like, ambiguities in the spec that need to be ironed out. So as far as we're concerned, this is we're now several cycles into saying this, yeah, this draft is complete and implementable. So where does this leave us? Yeah. We have a couple of sort of nits to sort out. I mentioned the signature identifier that is a collision with something else defined somewhere else in in CMS. We need to brush up the FIPS references, the sample data. We just need to make sure it's all back. I was literally finishing the hackathon yesterday, so we just need to square that all up. And then I think we're spitting distance from shipping this document. And that's all?
[00:14:16] Ned Smith: You had That's all. Five minutes for q and a and five minutes for discussion.
[00:14:24] Mike Ounsworth: Which I may be relinquishing back to you.
[00:14:28] Kathleen Moriarty: Could be good. It always gets eaten up.
[00:14:30] Ned Smith: Yeah. I mean, if you don't need the time, that's fine.
[00:14:32] Speaker 9: Should we do before the time?
[00:14:36] Michael Richardson: Yogesh.
[00:14:37] Yogesh Deshpande: Hi, Mike. Thanks for the excellent presentation. You said your title of the document is evidence encoding for HSMs. Was it it that specific to HSM? Because I felt that this is general key attestation principles laid out in the document and in your slides.
[00:14:55] Mike Ounsworth: Right. So what binds this to yeah. It's a fair question. Container. We're defining a container format, and we're defining a set of claims, which you're allowed to ignore. So if you ignore the set of claims we're defining, then sure. It's totally generic. The claims we're defining includes things like, did you boot in FIPS mode and PKCS 11 not extractable, which are clearly, like, p 11 specific semantics. Mhmm. So in that sense, it is it is a it is this this is designed for and the claims we define are specific for p k s s 11 devices, but it doesn't have to be, of course.
[00:15:33] Yogesh Deshpande: Yeah. I mean, because if tomorrow n number of such technologies, you will end up postponing n number of such drops, which you could have generalized architecture, which could then fit in HSM or some other secure limits.
[00:15:48] Kathleen Moriarty: I'm gonna help here. I think I think the scoping personally, I 'm wondering which chair what which hat I put on. So from the progression of this draft
[00:16:01] Usama Yasasin: Yeah.
[00:16:01] Kathleen Moriarty: The framing, I think, is particularly important. And the reason is that there was quite a bit of confusion with that with the model and the differences from, you know, the the TPM and the familiarity with people in the group from how HSMs are used and the PKCS 11 interface. Right? So that the hardware, the interface to the hardware, you know, so the PKCS 11 is different than with the TPM. I need more coffee. I'm sorry. And so I think the framing is really important just because he is tapping into the p a c s 11.
[00:16:45] Mike Ounsworth: Okay. Thank you. Yeah. And I know Hank is also and I don't want to at the risk of jumping on another landmine, but Hank has also brought up that HSMs don't always have the stack of turtles the way you expect in a in other types of devices. And so
[00:17:00] Hoda Alkhzaimi: this different.
[00:17:01] Mike Ounsworth: It is different. And so you may have to the verifier for this may need to make some assumptions that are different from assumptions you make when verifying other things. And there's a few there's a few subtle differences between, like, an HSM attestation and other types of devices that have keys in them.
[00:17:18] Ned Smith: Yaron?
[00:17:22] Yaron Sheffer: Yaron, Jeff, really a clarification question, and I'm new to this draft. Apologies. In HSM that's not a CA, do we really expect it to have an ASN one encoder? Or in other words, is ASN one the right technology as opposed to possibly smaller stuff like Cozy?
[00:17:50] Mike Ounsworth: Sure. I know lots of TLS servers that run like an EnShield or a Talos and hold thousands of TLS keys in an HSM, and you might want to attest those.
[00:18:00] Yaron Sheffer: No. That's not my question. You you want to attest keys. My question is whether ASN one and specifically ASN one encoding is the right technology for an HSM.
[00:18:14] Ned Smith: You mean during coding?
[00:18:16] Mike Ounsworth: You mean
[00:18:16] Yaron Sheffer: During coding? Yeah. Yeah. Yeah.
[00:18:19] Mike Ounsworth: So okay. So we started this work back in 2022 maybe, and we started it by getting the guys from EnShield and Talus and Udimaco and Crypto4a all in the room, and we said, alright. We we are the big HSM vendors. We need a way to attest to a CA. And this started with Cab Forum. So this work all started because Cab Forum says if you are going to submit a CSR to a public CA for a Microsoft code signing cert, that key must be in a FIPS level three module. That is a Cab Forum baseline. And we said we have no automated way to prove this. And it was like CSOs of, like, software companies signing letters with photos of data center racks. And look, it says OnionShield on the rack. And I was like, this is wild. There's we surely could do something with software. So that's where this came from. And all the HSM vendors got together, and we all said, we're all PKI shops. We're all PKI people. We're devices that speak p 11. DARE is the natural language for this consortium of devices.
[00:19:25] Yaron Sheffer: Okay. Thank you.
[00:19:34] Usama Yasasin: Some of you, Chris.
[00:19:36] Ned Smith: Both our note takers are occupied. Can somebody take notes? So the
[00:19:40] Usama Yasasin: Yeah.
[00:19:43] Mike Ounsworth: The. Okay. Usama, please. Description is not
[00:19:48] Henk Birkholz: that they're taking. Yeah. I'm highlighting that.
[00:19:50] Usama Yasasin: Osamara, to you, Dresden, you mentioned that HSM is different from other technologies that we are aware of, like TPM and TEs and so on. In the draft, is there a section which kind of describes for general audience that, hey. This is the actual difference between this and this, and this is how to interpret this terminology and all that? Is there a section in the draft already, which is kind of distinguishing this HSMs to other than the formats? I'm not talking about the formats in itself. But the technology from Rats perspective, is there a section which describes that?
[00:20:25] Mike Ounsworth: Hannes, so we have a fairly lengthy introduction. I forget. It's sort of grown and shrunk over time, but we have a fairly lengthy introduction with pictures and boxes and arrows and stuff that describes this is the kind this is this is the architecture of the platform that we're intending.
[00:20:41] Jean-Pierre Thibert: Section three has a lot of terminology, and I believe it addressed what Usama is is asking for.
[00:20:48] Ned Smith: Yeah. I
[00:20:51] Speaker 9: JP responded to that already. So we we we went obviously, the document changed a number of times, and we've been bouncing forwards and backwards on how much description background description would be needed. We had also that experience with the working the CSR at the station, and Mike was just talking about the history of all of this. So So it's I think, one, you all have to look into the document to see whether the current text fulfills that need. In the experience we have with the CSR test station, some of the authors are here, was we provided a lot of context. And then later on to be told, don't provide that context and was all ripped out. Like, we spent basically, like, literally 20 pages describing all sorts of context to be later ditched, which is sort of like a very unpleasant experience. So we need to find a a fine line here where we don't write a book, versus, like, providing still useful information.
[00:21:52] Mike Ounsworth: I mean, maybe that question sort of bounces back to Usama and other working group members is we're getting close to us on work
[00:21:57] Michael Richardson: group last call. Please look at it.
[00:21:59] Mike Ounsworth: If it's not clear, please tell us.
[00:22:03] Henk Birkholz: Hi. This is Hank. Please look at it. What's so to reply
[00:22:13] Ned Smith: to
[00:22:13] Mike Ounsworth: You're an author?
[00:22:16] Henk Birkholz: Should know.
[00:22:18] Jean-Pierre Thibert: Let's put a microphone.
[00:22:19] Kathleen Moriarty: K. We have
[00:22:20] Henk Birkholz: Also, replying to Sharon's question. No. ASM one is not the preferred evidence, how much in any case. But for CARA HSM scenarios and PKCS 11, it very much is and it will never change. So as the bow die diagram in RFC nine thirty four tells us, there's a lot of representations. And in this case, it makes a lot of sense. Do we want to be this an example for future things that for evolution are remote at the station? No. But do we have to do it here? Very much yes.
[00:23:05] Mike Ounsworth: Yeah. Are we trying to do eat in dare? No.
[00:23:08] Henk Birkholz: Yeah. No. No. No. ASM one web code.
[00:23:14] Ned Smith: So, Sam, are you done? It's not a joke.
[00:23:19] Usama Yasasin: So I'm again so if you tell precisely which section is it, I think it will be very useful. Like, saying that, hey. The big section three has something there, so that that's not very useful.
[00:23:31] Mike Ounsworth: Okay.
[00:23:31] Kathleen Moriarty: Okay. So I'm speaking for, Carl Wallace who put into the, the the queue. Why TBS like instead of signed data reuse? This was part of the signer identifier comment, and his question is relative to the data model in section five. If that's just too much detail and you wanna answer on list, that's an option too.
[00:23:59] Mike Ounsworth: Unless JP has a brilliant answer. Don't think I can answer that live.
[00:24:05] Jean-Pierre Thibert: We could we could rename it if if it lines up better for sure.
[00:24:09] Mike Ounsworth: Is that a renaming question or a structured question? We are I gotta check it offline.
[00:24:15] Kathleen Moriarty: Okay. Thank you.
[00:24:26] Mike Ounsworth: Can I sit down now?
[00:24:28] Kathleen Moriarty: Yes. Next speaker.
[00:24:42] Paul Howard: Make sure I'm not presenting with a coffee moustache. Just make sure I'm not presenting with a coffee moustache.
[00:24:50] Kathleen Moriarty: Oh, well.
[00:24:51] Paul Howard: And there we go. Okay. So there's my time. Is my time started? That's right. That's right. Hang on. Fifteen seconds. Is that my clock? It's worse than the hackathon.
[00:25:06] Kathleen Moriarty: Going to get an extra ten seconds. Yeah.
[00:25:08] Paul Howard: Sure. Okay. Okay. So so so hi, everyone. This is this is co serve. The name of this draft has not changed, and I'm still Paul Howard, there's no update there either. Just click on working. I can't seem to advance the
[00:25:28] Ned Smith: slide. Yeah.
[00:25:32] Yogesh Deshpande: Transcript for course that is possible. Course that
[00:25:35] Ned Smith: Try it now.
[00:25:37] Paul Howard: Okay. That seems a little better. Thank you very much, Ned. Okay. Very quick guide for the uninitiated. This is the Rats architecture, and that is the space in which co serve plays. Co serve is a conveyance protocol that helps verifiers consume endorsements and reference values from multiple complex supply chain sources. And so if you're interested in those particular vectors in the Rats architecture, then CoServ is probably for you. If you are somewhere else in the Rats architecture, then you might be less interested. Why have we done it? We've done it because it's really in recognition of the fact that the idealistic boxes and arrows in the Rats architecture are somewhat betrayed by the real world. And we think there are, you know, a growing number of potential producers and consumers, producers of hardware, firmware, software, or aggregated collections of those things. And also consumers in the form of verifiers that might be online verification services or might just be likely code linked into applications. So we think some standardization across the middle there is useful for the industry. Co serve provides a query language. It takes what rats already has, which is co rim, builds very heavily on co rim, adds a query language for querying, collecting, and caching that kind of collateral using standard HTTP caching semantics. Right. We get to the meat of it then. So what have we what have we actually done since the I t f one 02/05? Well, we have a feature. We have actually extended the query model of CoServ. So CoServ started out life purely based on a tester environment. So you would describe an environment in the query, and the co serve provider would use that environment to deduce the artifacts and the things that it should produce in response. But we figured if we have a query language, then actually, sometimes you might just want to do a lightweight query for a rim document with a specific ID, you know, either a co rim ID or a co mid ID, or co swivel or something like that. So we now have sort of bifurcated the query model. There is still the environment based model that works just as it did before. But there is now also this this this alternative rim identifier based document as well. And the results that structure likewise has has a variant to convey just wholesale written documents back in in response to that kind of query. On the maturity and progression through the working group side of things, we think we are approaching WGLC. But I have some comments on on the on the other side of the slide to to talk about that. I do want to say thank you to the chairs for organizing the early review from HTTP directorates that is scheduled and I think is due to come in at the end of this month. So there'll be some interesting feedback there that we can take account of because there's quite a lot of HTTP usage in in the draft. So we think that would be very valuable. We have a fairly small number of open GitHub issues. Some of those are quite nitty. So we'll probably have to get that number down pretty quickly. Features on the road map. So there is some active work actually going on right now. We didn't manage to quite get it to come together for the drafts that we brought to this IETf, but we are using the environment based queries as a way to query for topological information of the testers rather than just the direct reference values and things. So this is basically your in in Corinne, this is your domain modeling, so domain membership and domain dependency. It would be possible in CoServ to issue a query for that information. So you get the topological information first, and then you can make more targeted queries for the testing environments within that topology. So that's a feature that we have in flight and there's, you know, open pull request on on the draft, but we just haven't quite got it fully together into a mergeable state yet. So, yeah, on the maturity thing, Corinne data stabilization, obviously, you know, CoSERV is built on CoRIM, so it has to necessarily queue up behind CoRIM in in terms of readiness for publication. I think we're somewhat more confident now about the CoServ data model, but nonetheless, it is something that we have to say, yes, that's ready before we can say CoServ is ready. The slightly bigger issue potentially is the dependency on COTS. That's a common trust concise trust anchor stores. I will talk about that on the next next slide. Open GitHub issues, as I said. I do think at this point, and I guess there's another request to the chairs. Sorry. I'm always coming here with requests. But I think assigning it I think it would be prudent at this point to think about assigning a a document shepherd Great. Given that take the size of the group.
[00:30:51] Ned Smith: Gonna ask for volunteers. So wanna
[00:30:55] Kathleen Moriarty: We'll do that on list.
[00:30:56] Ned Smith: We'll do it on the list, but Sure. That's what's gonna happen.
[00:31:00] Kathleen Moriarty: Okay. Oh, fantastic.
[00:31:02] Paul Howard: That would be wonderful. Yes. Thank you, Yogesh.
[00:31:03] Yogesh Deshpande: Who was that? Yogesh. Yogesh.
[00:31:10] Paul Howard: Cots. Right. What's what's what's cots? What's the problem? So co serve at the moment is taking a normative dependency on an expired draft. That's the the trust anchor stores draft. So the CDDL model for co serve pulled out this fragment of it here. One of the things you can query through co service for trust anchors. Trust anchors can take the form of attestation key triples coming from co rim. But we we have an alternative structure for trust anchors, which is based on cots statements from the trust anchor stores draft. And you can see here that the CDDL hits a kind of red signal at the point where it tries to import COTS because that's coming from an expired draft. And we need an answer to this problem. Right? So we we have various options that we've discussed among the editor team, but we have not yet discussed on the list. Think what we will be doing next is just bringing that conversation to the list. You know, we could look at just removing that dependency entirely and saying that trust anchors can only be out of station key triples, or we can find a way to abstract it so that the dependency is not direct, or we could do something else. We'll fire off a discussion on the list to try to reach a conclusion on that. Okay. So running code, I would say evolutionary rather than revolutionary this time around in terms of running code updates. But we do have co serve libraries just for parsing and manipulating co serve objects, and those are available in both Go and Rust. They're all part of the Verizon community project. And basically, we've updated both of those to the latest draft. So, crucially, that includes the shift of the data model to support the two different query types so that the environment based queries and the rim based queries, those are now both fully catered for in in the go and rust libraries. So that's a healthy update. Running code updates end to ends. So we we we have this we have this great end to end sort of validating proof of concepts that we've been building with others in the Verizon community. We brought that to the last IETF. I just want to remind people that it does still exist. It does a full you know, evidence gathering, co serve query, co serve results, evidence verification flow. So it is, you know, quite quite validating as as a piece of work. There's a repo for it, which is we which is there. Again, the update is more evolutionary than revolutionary. We've basically been revising and re spinning components to take account of various small scattered breaking changes that have occurred throughout the stack, you know, like, you know, the latest current draft, the latest that this uses ARM CCA. So there are CCA profiles for evidence and for endorsements, and those have been updated. So it was really just a case of, you know, lift lifting all the boats and and bringing everything back up to a working state. So what we haven't done yet in this draft, I did look at it in the hackathon. It would be nice to demonstrate the rim based query model in this end to end flow as well. I definitely have an ambition to do that. I I wave waved around it a little bit at the hackathon, but all I managed to do was gather some observations of, you know, here here are some things that need to happen in in order to support that. Wasn't able to actually demonstrate it in the hackathon. Some future stuff. So Verizon community is is pushing ahead in terms of implementing co serve for various use cases. One's quite an interesting one because it's a little bit sideways. It's not so much using co serve as a query language, but more using it to control things. So in Verizon, there's an endorsement provisioning API where you can submit you can submit co rims. What has been proposed, and I don't know whether it's been implemented yet. Can you remind me? Has this been implemented yet? The the activate and deactivate based on co serve queries? I can't I can't actually I okay. Okay. So might might have might already have been implemented. But the idea here is that you're using co serve not to query for resources, but instead to identify resources and activate them and deactivate them. So you, you know, if you have a, like, a firmware update sort of scenario, you can deactivate an old rim, you can activate a new rim, and you can do that based on co serve queries. So that's an interesting new, somewhat unanticipated, but perfectly valid use case for co serve. Four minutes. Thank you. Linking Verizon in multiple roles. This one has not been implemented yet, but definitely has been promote proposed go to go to the issue to read more about this. This this is about being able to instantiate the raise on both as an endorsement distributor and as a verification service and using co serve demonstrating how co serve can be used to synchronize endorsements and reference values between those two very different deployments in a a Rats like architecture. Thanks, as always, to all of these people. The collaboration has been very, very fruitful, very rewarding, and lots of fun. I'm very, very grateful to these people who who help build all the things I'm talking about. And also, I'm grateful actually to everybody who engages with CoServ in in any capacity at all. We're very, very grateful for the feedback always. Some resources there, the draft, the GitHub repo, and a couple of recent presentations I've done on the CCC attestation SIG and also in the OCP security working group, and that's me done.
[00:37:27] Kathleen Moriarty: We have two and a half minutes. Is Sama?
[00:37:31] Usama Yasasin: Sama, I have long standing concerns on this, and somehow due to some reason, they're always skipped over. And I don't understand why that is the case. Like, the aggregator itself as an entity is still not clear to me why that is there. I asked for a justification for that, and I don't see from this presentation why or how that is addressed actually. And, specifically, what I want to raise concern is that if that entity is malicious, it breaks the whole security argument for the whole draft system. Do you agree with this before we go into, like, move next? So if aggregator is malicious, it breaks the whole security argument. Do you agree or do you disagree with this?
[00:38:24] Paul Howard: I think I disagree with that as a statement if we are treating of the draft.
[00:38:27] Kathleen Moriarty: And we only have one and a half minutes.
[00:38:29] Paul Howard: In this group, we are treating of the draft, not of any implementation or or deployments. And what CoServ says about aggregation, there is no there is no evasion on this point. I mean I mean, co serve does not introduce aggregators, it simply recognizes that they may exist. And it's a transparency play actually is just giving you a way to explicitly describe a process that may happen anyway, implicitly. So CoServ is not introducing or sort of dictating what a a deployment looks like.
[00:39:04] Kathleen Moriarty: I'll take a chair action to read the draft, read your comment, and settle this.
[00:39:13] Paul Howard: Thank you. Thank
[00:39:19] Kathleen Moriarty: you.
[00:39:19] Paul Howard: I think we're done. Okay. Thank you very much.
[00:39:22] Ned Smith: Alright. Up next.
[00:39:44] Yogesh Deshpande: You can see sharing the slides now.
[00:39:46] Ned Smith: Yeah. On.
[00:39:52] Yogesh Deshpande: Hello, and welcome, everyone. I hope you are enjoying the session. Today, I'm going to talk about CORIM, but just for the newcomers who might be here, I think Paul briefly touched upon CORIM. Basically, CORIM is stands for concise reference integrity manifest. It's a data format for supplying reference values and endorsements to an attestation verifier performing the job of remote attestation. So it's fundamental the operation of remote attestation. Next slide, please. Clicker.
[00:40:22] Thomas Fossati: Here's your focus.
[00:40:24] Kathleen Moriarty: Yeah. No. Thank you.
[00:40:27] Yogesh Deshpande: So here, I'm just describing a snapshot of progress from the previous ITF. As as probably who's who are following the previous ITFs, there is we had requested chairs for a lot of reviews, HTTPS directed review, security review, art art reviews, and many reviews. So thank you all in the community who have reviewed the document and provided valuable feedback, and we have been very busy incorporating the feedback. And as part of that review, we have done major restructuring of the CoRIM document. We have folded sections eight and nine. This doesn't make any sense if I say that. Just to highlight, section eight was describing the various phases of appraisal while section nine detailed about reference, verify implementation. So we just folded that to make the context more meaningful. Then I we applied generic condition addition patterns to the enrollment claims to pull ECTs. What I mean is that you basically break down the e c external triples into condition addition pattern so that they are easy for a common approach of match and augment. And then instead of terse process, we added pseudo code for internal transformation of the reference and the triples, all the triples, as well as the coding processing algorithm now has pseudo code instead of, language. And we consolidated introduction section so as to have a very high level context of what has been going on in the reference verifier algorithm section so as to make the readers more understandable of what is going to come next in the subsequent sections about the reference verifier. And, of course, general tidy up and minor improvements were performed to make it look more neat. So okay. Next slide, please.
[00:42:18] Kathleen Moriarty: Clicker. Clicker. It's in
[00:42:20] Yogesh Deshpande: your hand.
[00:42:22] Kathleen Moriarty: It's okay.
[00:42:23] Mike Ounsworth: So Sterling.
[00:42:24] Yogesh Deshpande: As I mentioned, I'm just going to reiterate that restructuring helped us a lot. It incorporate the feedback, and the document now is much more consistent because it follows a unified approach of match and augment whether you are processing any kind of triple, whether it is reference value, endorsed value, endorsed value, conditional endorsed value. All these triples follow a common match and augment algorithm. And, of course, when transforming the TURCE text to pseudo code, we realized that a lot of common pseudo code can be extracted into abstracted into functions, which can be reused from multiple places, thus removing a lot of duplication, thus removing the thus reducing the document size and helps improve the readability of the overall document. And this also helped a lot in when we split the con triples into condition addition pairing, as I mentioned, in the internal representation that simplified the processing algorithms very much as well. And so we believe that we're doing such a big exercise, and thanks to Thomas for starting the heavy lifting on this and my coauthors, Ned and Hank, and me kind of chipping in, and we done I hope we have done a good job, and I would hope that this would incorporate all the review comments, which broadly been implemented now in the document. So I'm going to go delve a bit deeper into the restructuring because I believe that Corim is becoming extremely popular, and it is our job to help understand the Corim to the entire community. So I'm just trying to go through a bit in detail about this just to let you know that this high level flow is not being updated since light last ITF, but this just sets the context for the subsequent slides where you see the external reference values and endorsements generated as scoring files submitted to a Rats- verifier, and internal to the Rats- verifier is the CoRIM processor. I'm going to go into deep of these blocks, so I'm just going to skip to the next slide so that, I can focus. Now the green box, highlighted on the right is the stuff which I'm explaining on the pseudo code on the left where we do the validation and internal representation and transformation of the external triples into an internal representation where the external triple is broken down into, as I mentioned, condition, addition, ECTs. All the triples x here represents any triple is transformed into an internal representation with has conditions and additions. I'm not going to delve down deeper further because of a limited amount of time. I'm conscious of time, but I'm happy if someone approaches me later down to understand the algorithms in a deeper flow, and I'm more than happy to spend more time with them. So up after the internal representation, of the triples, I'm going to explain how the evidence gets transformed. Just to be clear, evidence transformation is clearly out of the scope, but here, we are just explaining it in a very high level so that it makes sense because evidence is where the appraisal processing starts. So the evidence is also validated, and it's transformed into ECTs. And this is an algorithm to show that the evidence claims are how the evidence claims get into the e c ECT structure of the ECS. And this is just an initialization slide where when the appraisal starts, the triples internal representations are loaded into the ACS. Sorry. It's loaded into the staging area. Initialization stage at this on the left is the staging area initialization, and the evidence goes into the ACS directly because, you start the appraisal with the evidence. And this is the kind of core meat of the algorithm where each time you you load a triple from its internal representation from the staging area, you match it with the whatever is in the ACS. So at start, it is evidence is it is matched with evidence. And once the condition from the staging area ECT is matched with the ACS, if it is satisfied, you may want to perform some additional checks for consistency in the ACS before subsequently adding the ECT into the ACS. And this is how this is a generic architecture of match and augment. This is applied to all triples, whether it is reference value, endorse value, or, domain dependency or domain membership triples. And then subsequently, after the match and augment has complete is complete, you hand over the ACS for subsequent processing. Subsequent processing could be applying appraisal policy for evidence as one stage or adding verifier added claims or transforming the ACS into an external representation for attestation results. These are clearly out of scope for the document, but this is explained here for the sake of completeness so that the reader gets the overall picture of how the entire end to end reference verifier would work. And we had done some general tidy up based on some of the comments, especially, like, we had a detailed certificate validation parts, but, somewhat some reviewers high highly correctly pointed out that this is just duplication of, standards from RFC five two eight zero for certificate validation. So we kind of now referenced it. We clarified that at the in the staging area itself, it would be advisable to remove the cyclicity of domain memberships so that the processing becomes much cleaner down the line. And then the locator map in CoRIM is just an advisory that you can use the locator map, but there is no kind of hard mandate on it. Must be correct. If it is there, can be used. Great. And, we had some some questions from some of the, external users about how to do the if a single target enrollment may have multiple reference state, how to encode that. So we have clarified that the encoding should be in separate reference triples separate reference triples when they have multiple reference states for a single target enrollment. So next steps. We believe that, bulk of the restructuring heavy lifting has addressed almost all the comments which we had. So we request, all the reviewers who has reviewed the Quorim document to reread again once quickly sanity check to understand, does their comments have been addressed or not? So that that feedback would be really appreciated. And and post the heavy lifting tidy up and restructuring, we believe that there are still some minor issues, which we these are some of the top level issues. I'm not going to go into the details of all these issues, but there is still a bit more tidy up to be done before we we go to the next stage. And we believe once this tidy up and one final check from the all the reviewers is done, We believe we are ready for another working group last call in either the next ITF or just prior to the next ITF. So that would complete the document going into the standards. I think that's the end of my presentation on Corinne. If there are any questions, I'm happy to answer. Okay. Then I can give ten minutes back to
[00:50:16] Ned Smith: the Great. We'll take it. Again.
[00:50:23] Yogesh Deshpande: We can move on to the next presentation. Okay. Now I'm going to talk about one more interesting topic about remote attestation with multiple verifiers. And with me joining is June Zhang and Huda from Huawei, with active contribution from Henk. But I must also say that we thank Thomas Fassatti from NVIDIA, Gara from Orange, and from Ubitec who have been very active contributors and very patient reviewers and contributing to the standards. So thank you so much to all of you. It's a joint presentation from all of us. Oops. Why the next slide is not working, the buttons?
[00:51:14] Yuan Xiao: Can you please Yeah.
[00:51:14] Ned Smith: I have to reboot the filter every time.
[00:51:17] Yogesh Deshpande: What happens?
[00:51:19] Ned Smith: Try it now.
[00:51:24] Yogesh Deshpande: Try it. Yeah. Yeah. It works. So today, I'm going to talk very briefly. I hope this presentation is also very brief. Today, I'm going to talk briefly about the current document status, progress implementation in the open source project version, and discussions and topics that arises because of multi verifier or composite attestation, overall architecture in general. So multiwifi draft is now officially adopted as a Rats working group item. So congratulations. Well done, team. It's an outstanding work resulting in excellent result. I believe this is a very important work for the Rats community, and thank you all who has contributed. And I would like to take this opportunity to thank all both the Rats chairs for their leadership and valuable guidance getting it adopted. Thank you so much. So as after once the draft got officially adopted, me and Henk, together, we moved the document into the Rats working group repository. And with the painful efforts, we managed to retain all the commit history and the previous work, issues, and open pull request are successfully now moved into this new repository. So this is the new repository, and if you have any issues, concerns, feel free to raise it on this repository from now onwards. Okay. Now I'm going to talk in detail about the open source implementation of the multiverifier stuff and composite attestation we are doing within the open source project where I joined. So last three months, we are busy implementing some of the attester side of things the library, because we felt that this is fundamental if you want to do the verified implementation. Because as I will explain you, this composite evidence library generates composite evidence, and library needs encoding and decoding APIs so that the verifier can also invoke it when it's processing the component of composite evidence. So we have now a fully working library support for, an APIs for setting, validating, and encoding and decoding the leader tester claims. So we have a, if you see the Rats architecture, RFC nine three three four, you have a composite device which has a leader tester and component testers together in a composite device. So we have implemented that library for generating token for this composite tester, and so we have a API to set the leader tester claims. And we can set the full composite tester token using a CMW collection. So we have, APIs for CBOR encoding and decoding that, as well as, we have mechanism to sign the overall token, and the verification of that signature verification of that. So the both the APIs, all the APIs of setting individual component attested token as well as the signature and verification of the complete, attested to composite attested token is available now. And, now I'm going to the core multi verified lead verified implementation where this is the overall architecture, high level architecture of this, where you have a REST API to handle the composite evidence with a media type, and then you invoke a parcel table. Parcel table will identify which parcel to invoke because, of based on your media type, you could have multiple parsers, like CMW collection parser or each sub mod parser. And then once you invoke the right parser, you get a number of individual component tokens with then media type. And then you invoking the dispatch table at the bottom, you invoke the appropriate clients, and the clients communicate with external verifiers. Or internally, if you are implemented within Verizon, any verification like CPU, it will the client would invoke that. Otherwise, you can contact Intel Trust Authority for remote verification or NVIDIA GPU verification. This is how the multi verifier functions happen. And on a private branch, we have these, these elements of the architecture complete, but some of them is still work in progress. And once we complete that, we will do the full integration and then merge those changes to the main branch after review. Okay. So while discussing multi verifier and composite attestation in the various design meetings, we we discovered new and interesting problems, but they are I must say that these are new challenges, and the new challenges are of discovery. How does verifier discovers other verifiers to complete the composite at a stay station verification? And, of course, discovery can be taken at one level up. You can have multiple endorsement services. How do we discover that? So it's not I I believe that this is not specific to just verifier, but it is beyond the verifier as well. Discovery is a problem. Not a problem, but a interesting challenge to solve. So I I think, we in Rats community should take a look at our discovery at a slightly higher level. Second is the trust establishment. How do verifiers trust each other? If there are n number of verifiers doing the verification, how do they trust each other? The ranked party also now needs to trust n verifiers instead of one verifier. So does we bootstrap that kind of trust establishment for the entire ecosystem? And in in the composite tester meeting, another third aspect which we ex which we discovered is that the freshness handling. With the single verifier, the verifier or the relying party sends a single challenge to a tester, and it it just use that challenge to encode the evidence. But now on the device, you have a number of components. So each of these components may have different challenge requirements. And but the relying party or a lead verifier may just send one challenge. So how do you mix and match? How does the non set adjustment happen? So those kind of challenges, we still need to address in the Rats community. And I believe that going forward, we will be addressing that. So the very first discussion on this is in a side meeting, which is organized on Friday, 10AM here in Vienna. I would love to hear your feedback, your ideas, and would be happy to discuss and progress these issues going forward. I would like to ask one thing to the draft chairs that as far as the multi verified document is concerned, it is in a very stable state. So I would request chairs for the subsequent reviews so that we can take it to the logical conclusion and go for working group last call after the reviews. So my humble request to the chairs if they can organize all the reviews required to take it to the next stage.
[00:58:10] Kathleen Moriarty: Okay. Can we get some volunteers for reviews? Hannes- Hannes. Michael?
[00:58:18] Yogesh Deshpande: Your room.
[00:58:20] Kathleen Moriarty: Paul. Paul. Thank you.
[00:58:24] Yogesh Deshpande: Mark.
[00:58:26] Kathleen Moriarty: Thank you. I need more coffee. Anyone else? K. I'll also aim to review it.
[00:58:38] Yogesh Deshpande: Oh, thank you so much.
[00:58:41] Kathleen Moriarty: Anyone else? Anyone in the, anyone remote would like to review as well? Just put your name in the chat, and we'll make a record of that. Much appreciated. Thanks for your work.
[00:58:54] Michael Richardson: Thank you.
[00:58:55] Kathleen Moriarty: Do have a queue. Hank is up first. Yeah.
[00:58:59] Henk Birkholz: Hi. This oh, that's more than one. Yeah. Hi. This is Hank. I just want to highlight that these challenges will not scope into the document.
[00:59:07] Kentaro Takahashi: Yeah.
[00:59:08] Henk Birkholz: These are adjacent issues, and we also will not do a zero context discovery like a dawn. Sorry. And so this has to be more specific to the Rats ecosystem, maybe some context specific discovery, maybe some context specific decision making and trust establishment. There are existing building blocks, of course, and Michael will elaborate on that, I assume. And but but this is very important to highlight that this is not part of the existing document. It will be an incubator for for future work.
[00:59:50] Kathleen Moriarty: K. We only have just over a minute, so please make it brief.
[00:59:54] Ned Smith: Oh, we have ten minutes from the last two. Yeah.
[00:59:56] Kathleen Moriarty: Oh, we have ten minutes. Okay.
[00:59:58] Usama Yasasin: So I've already
[00:59:59] Yogesh Deshpande: yes, Usama.
[01:00:00] Usama Yasasin: I've already given my review, so there is no need to give a second review. So the comments are unaddressed. If you go back to the slide, which was new challenges.
[01:00:09] Yogesh Deshpande: Yeah. Usama, just to clarify that. So We have already identified what you have raised here. Right. That needs a broader discussion as a separate discussion from the multi verified document. So I think Hank was very clear to say that we are not going to scope creep. You had a concern about the trust establishment of relying party to and verifiers versus one. If I'm not mistaken, that was your concern. And I think I've precisely listed this to be addressed as a new challenge outside of the multiverifier document. I wanted to advance clarify that before you kind of bank on the same question again.
[01:00:42] Usama Yasasin: So what I'm saying is that saying this in the meeting is fine. Having it in the slides is fine. But is it acknowledged in the draft itself that this is a problem in the security considerations or not?
[01:00:55] Yogesh Deshpande: I don't think this is needs to be explicitly stated there. We are
[01:01:01] Usama Yasasin: I disagree.
[01:01:01] Yogesh Deshpande: At the top level, we have said that this this increases some of the security of the because of multi fire fire may increase security in certain situations. That's all we have acknowledged that. Yeah.
[01:01:15] Mark Baugher: So my comment is not specifically on this draft, but as we look at things like location verification
[01:01:22] Yogesh Deshpande: Yes.
[01:01:22] Mark Baugher: And, like like
[01:01:24] Ned Smith: Mark
[01:01:24] Mark Baugher: I think a device with location sensors should be composite a tester, and they should snap together. I'm looking forward to seeing that.
[01:01:31] Yogesh Deshpande: Absolutely. I
[01:01:31] Mark Baugher: haven't seen it yet. Maybe I'm just not reading it
[01:01:33] Yogesh Deshpande: right I think, Mark, it's a very valid point and a valid concern. What I believe is location sensor can have its own attestation, and we can aggregate this attestation as part of the composite attestation. And we must do that. Perhaps yeah. I think maybe we can create a new draft for addressing how the location incorporates as a claim in the composite attestation story, and I would love to see a new draft specifically for geography because as the workloads get deployed in different parts of the world, there are some governance or legislative requirements of workload not moving outside a specific geographical zone, and I believe we need to have a new separate draft for that.
[01:02:23] Mark Baugher: Yeah. And
[01:02:25] Yogesh Deshpande: then we should use some of the work from here and reference in the new draft that how the composites needs to be constructed, and let's work on that. And I I think I I I fully acknowledge that we should do some work on this. Yeah.
[01:02:38] Ned Smith: Yesterday, there was a buff on discovery, which is aiming towards sort of a a generalized discovery mechanism for the Internet. What do you think is the right way to position this this bullet point?
[01:02:53] Yogesh Deshpande: Exactly. I was I attended the doc the bot to completion. And, I thought that their term entity was much more generic to say that entities could be notes. But later, I realized that in their agenda, they realized that it could be a lot of scope creep in their BOF. So they define the entity as a narrow AI agent to start with, if I am not mistaken. Yes. So then I realized that because they are only in scoping their they're narrowing their scope to entities as AI agents, I think we should create a new discussion within the Rats community on discovery, and we should address within the Rats for our attestation requirements for discovery, whether it is for endorsement services or for multi verifiers or any discovery of attestation specific nodes. That's my view, but this is purely my personal view. Yeah. Okay.
[01:03:51] Kathleen Moriarty: Okay. So I'd say any work on that, we'll have to take in context existing methods. Right? So that if we don't have to create something new, we're not. Yeah. Thank you.
[01:04:01] Yogesh Deshpande: Yeah. Thank you so much. Ned, you have your hands up. I'm happy. Okay. I saw you in the queue as well.
[01:04:15] Daniel Migault: Hank.
[01:04:16] Henk Birkholz: So hi. This is Hank again. Again, zero context discovery, which I think Dawn still is, is interesting. It was a nice comment. I forgot the who said it. Like, zero context discovery on the Internet is impossible. Zero as a context specific discovery in an authority, or in a certain domain solved. What are we doing here? So that was one Dawn comment. At the end, Eric was pretty as one of our ideas, was pretty happy with the result of Dawn. I just have to say that it does not seem to apply here. Named entity discovery is something we do. So under that catchphrase, I think, yes, we are in the scope of DWN, I think the scope of dawn will change drastically. Also, the the the the assumption that the review about agents is premature. So yes. So all of these things happen, and I think we should not be dependent on that. We should just go on. We have have have certain discovery mechanism that I then so on.
[01:05:29] Yogesh Deshpande: Absolutely. If you wait for Don to and they may say, okay. Sorry. This is getting too much. We are any generic notes are out of scope, and then we will left out. So that's why I said that we should discuss start discussing within Rats working group. Yeah.
[01:05:46] Usama Yasasin: So about the discovery point, is there something that's maybe building up on this Hank's comments? What is really specific to rats in this? Do you know exactly? Like, compared to Dawn, is there something really, really specific to
[01:06:02] Mark Baugher: rats or something that's inefficient?
[01:06:03] Yogesh Deshpande: Absolutely. Because as you see, discovery needs the right capabilities. But when you are using the word capability, it has a specific meaning in the attestation ecosystem. When I'm discovering verifiers. Right? The capability is what type of attestors I can verify. When I'm just I'm talking about endorsement provisioning, endorsement distribution services, what type of endorsements I keep. When I talk about endorsements, it could be a generic term, but in specific meaning in Rats ecosystem, the endorsements have a very specific meaning, reference values, and endorsements. So when I'm discovering that, the capabilities differ whether it is an AI agent node discovery against the discovery of a node which is specific to rats. Yeah? So capabilities drive that kind of discovery. Yeah.
[01:06:50] Usama Yasasin: So, like, endorsements and reference values, which you are saying that they they are different from Don
[01:06:55] Yogesh Deshpande: Yes.
[01:06:56] Usama Yasasin: That's a specific artifact that we have in Rats. I still don't see what is, like, in general terms from DON, if they do a capability for, let's say, doing something x. We have here x is equal to endorsement, x is equal to reference values, or x is equal to it can verify that something. So that to me is still a capability. So I'm looking at some fundamental difference, which I still do not see. Is there a real fundamental difference in what they are you planning to do might change?
[01:07:26] Yogesh Deshpande: You can club it all these things into one umbrella. I'm not saying that is not possible, but they will not do it because the for them, it is a scope creep. Yeah? They will say, why should I discover attestation notes in my AI agent discovery? Right? They will so my point is you can always club with them, but they should be willing to club. Right? If their scope is very narrow, then we will be left out. Right? That's what I'm saying. Yeah.
[01:07:47] Usama Yasasin: Right. I mean, we could utilize it.
[01:07:49] Ned Smith: Yeah. So so I think co serve is a form of discovery as well.
[01:07:53] Hoda Alkhzaimi: Yes. From Huawei. I have I have a
[01:07:59] Yogesh Deshpande: Can you please bring down the mic? It's not audible here.
[01:08:01] Kentaro Takahashi: I'll just bring
[01:08:02] Thomas Fossati: it up.
[01:08:02] Yogesh Deshpande: Or Or you can just pull it up.
[01:08:04] Mark Baugher: Yeah. Just Let's
[01:08:05] Mike Ounsworth: slide it. Okay. Oh.
[01:08:08] Hoda Alkhzaimi: Thank you, Okay. Just to give a comment because I attended also the down buff yesterday. At the conclusion at the end, the down chair was thinking that they will narrow the scope of down to be focused on AI agent. Exactly. So in I think in this time, during this period, transition period, it's good to continue to work on that's working group on this specific issue, and we will see.
[01:08:36] Yogesh Deshpande: 100%. I agree with you, Hoda. Yeah.
[01:08:40] Henk Birkholz: Yeah. This is saying basically the same thing. So we are con to put a conjecture on something that is not there yet. So just don't
[01:08:51] Yogesh Deshpande: Okay. I would like to give one minute back to you. Thank you. Cheers. Yeah. Looks
[01:09:00] Henk Birkholz: good now.
[01:09:14] Kentaro Takahashi: Hello. I'm Kent. Today, I'd like to share a short tax on report about remote attestation in deep provisioning use case. Next slide, please.
[01:09:29] Kathleen Moriarty: Oh, that's gonna be
[01:09:31] Mike Ounsworth: us. Thank
[01:09:31] Kathleen Moriarty: you. You
[01:09:32] Ned Smith: can't do that.
[01:09:32] Kentaro Takahashi: Okay. Yeah. So TIFF is an TIFF is an IT protocol for provisioning application into TEs, and it can carry remote attestation. At the same time, it does not define each appraisal step in detail. To get implementation experiments with how remote attestation work in TEE, we implemented a TAM that uses evidence for provisioning. In Rust terms, the TAM is relying party in this use case because it uses the attestation re result to decide whether to provision an application to the t, device. In our hackathon implementation, our time also included verify like functionality. So that's why I said our time consumes the evidence. And more concretely, our time directly verifies InterSGX quote evidence from the attester before making a provisioning decision. By implementing those appraisal sets in one term, we were able to identify possible boundary between reusable evidence appraisal and tip specific appraisal. In other words, between verify appraisal and relying party appraisal. Next slide, please. Okay. Yeah. So the basic flow is as follows. First, the TAM acting as a relying party sends announced to the attester, which is t enabled device. The key agent running inside the t generates evidence. In our implementation, this evidence is interest x quote that bind the announced together with the agent public key. The attestor sends the evidence back to the TAM, and our TAM verifies the evidence directory before processing with provisioning. Next slide, please. Here, yeah, I have listed the kinds of checks that appears in our in implementation. Some are about validity of evidence itself, and others are about whether its claims acceptable in the tape context.
[01:11:52] Ned Smith: Next
[01:11:53] Kentaro Takahashi: slide, please. I think we can now see a possible boundary responsibility split. The checks on the left look closer to verify, like, appraisal of evidence itself. The checks on the right look closer to TAM as a relying party interprets those claims for provisioning. So the observation from the the hackathon is that these different responsibility that ended up together in our TAM implementation. For maintainability and reuse, the generic part may be suitable for verify a component while the final provisioning decision remains with the term. Next slide, please. We have started, yeah, discussions with this direction with members of Verizon project. Verizon may be used not only in but also in other remote attestation context. For example, use cases discussed around a tested TRS in the seed working group. For that reason, we think it is important to continue discussing what should be verified by a generic verifier framework and what should remain specific to each relying party or protocol use case. We will be happy to contribute to Verizon community, and I would like to also very glad to hear any comments or questions from this working group. Thank you.
[01:13:39] Ned Smith: Sama, please please be brief. We have, you know, less than a minute for both questions.
[01:13:43] Usama Yasasin: I will be very brief. So the binder that you have used with the nonce and the public key, that's already proven to be wrong. And there is a CV already with a score of 7.5, so you might need to you might like to have a look at the resources I have put in the chat. Thanks.
[01:13:59] Kentaro Takahashi: Okay. Thank you. Yeah. I'll be careful.
[01:14:01] Yogesh Deshpande: I have no question. I would just want to welcome you to project version. That's what I was saying. So welcome.
[01:14:08] Kentaro Takahashi: Yeah. Thank you.
[01:14:09] Kathleen Moriarty: Thank you so much for your presentation and your work.
[01:14:31] Thomas Fossati: Hello? Hello? Can you hear me well?
[01:14:35] Ned Smith: Yeah. We can hear you.
[01:14:37] Thomas Fossati: Thank you. So, yeah, hi. Hi, everyone. I'm presenting draft-ietf-rats-daa, which is an e profile for trustworthy device assignment. I will tell you what trustworthy device assignment is in the next slide. But this is joint work with Matthew and and Hank, and I am presenting a view of Matthew. Next, please. Right. So the context the the setting is confidential computing with device assignment. So you have a NIC, you have a GPU, or a disk that gets pulled into the confidential VM trust boundary. And the question is, can you try the device? And the answer is, of course, not until it gives you evidence about its identity and state. And that's the gap that this draft closes. Next, please. Alright. And to be clear about scope, we are not inventing anything new here. No new device, attestation protocol, or whatever. We're just doing some sort of we're we're homogenizing device evidence around it. So the the the problem is that buses speak their own native formats, be it SPDM, CXL, CHI, and so on. But what we would like as drafts is that verifiers and relying party all convergent on on on a common vocabulary and all speak EAT. Right? So this DAT, this device decision token, which we propose is the translation layer that sits between native bus artifacts and standardized it claims. So you can think of it the way IP sits about many different link layers and, you know, you have one convergence point and many formats that leave underneath and can be plugged. Right? An interesting bit here is to notice that there's also parallel momentum on on a Linux kernel API for for retrieving this device evidence based on net Networking sockets, which is, you know, encouraging for real deployability and we're using in our prototyping work. Next, please. So, there's a question that we got. So why do this now instead of waiting for devices to go and and speak it natively? And because, you know, SPDM 1.4 has introduced this capability, but our observation is that in the same server, even in the bright future when SPDM 1.4 is well established, yes, you can have a device that speaks natively, but alongside that, you you will have an older SPDM device that can't, a legacy PCI hardware with with absolutely no SPDM support, and on top of that, you could have passes with conversion stories not yet written. So as IATF, we don't get to dictate what, TMTF, PCI SIG, and other SDU standardized at the bus level. What we can do though is define how their outputs can converge into RAS evidence. And critically what we think is that this heterogeneity is not is is is not a transition period that we're waiting out. It's it's going to be the permanent state of of affairs. Next, please. So this is the the system model. This is the model we are we're dealing with. You have a confidential VM with one or more assigned devices inside its TCB. And inside the confidential VM, there's a little tester itself measured as part of the platform evidence. And the thing that is being appraised here is the composite evidence, not devices in isolation. And, you know, on the other side of this big box, have an external verifier or a relying party that consumes this standardized deed. And in this in the system that we are dealing with, the data tester can play can play one of two roles. It could be a pure forwarder and just translate the native artifacts that that it received from the bus and pass it through unchanged or it can be a lightweight, lightweight internal, let's say, verifier that checks device identity locally and then based on the success of the operation repackages the result as claimed. Okay. Next, please. So here's, you know, the CDDL for the DAT. What is what is it in concrete terms? It's a NEET profile for for device claims. Right? This is the highlight. And and you can see the shape here. You have a need profile that identifies that this is a DAT. You have a need for freshness and and then you have these sub months, which is a map from a namespace qualified name to a device claim set. And this is the very simple framework we designed that is deliberately extensible. We are defining SPDM and PCI legacy for older hardware, but there's room for other buses in the future. And we and in section five of the draft, we have the the rules for for adding the other other buses. One thing to to note, it's not included in here, but that each sub mod carries it's an EAT in itself, it carries its own EAT profile. So both the bus technology and the version of the bus technology are explicit at that granularity. Right? So we can evolve the two the two things. And another thing to note is that, you know, the deity can stand alone or can be embedded inside a larger composite evidence message as as we've seen last week. Good. Next, please. Right. So okay. So this is taken with everything from from appendix b of the draft, and there's a picture that explains a composite test provided by that incorporates, crucially, that evidence in the larger composite evidence. From left to right, you see the challenges, none of it goes to deliver a fire through a standardized API, and then the lead test broadcast the nonce to the the sum of testers and collects platform evidence and device artifacts via that guest kernel API that I mentioned earlier. And what it does, it translates the native device outputs into that sub months. So here you see SPDMA, legacy PCI b, SPDMC as example sub mods name. But, you know, the later I will I will what the information is exactly. It then assembles everything into a single signed CMW collection and alongside that, it it it it puts into the collection also the lead testers' own evidence and and the platform evidence. And this is the aggregate that is then signed and the nose nose broadcast to this individual sub suba tester creates, basically, the binding that provides internal coherence of the of the whole assembly. The verifier then receives one composite message, breaks it down into the constituent pieces and handles the appraisal maybe locally, maybe dispatching to sub verifiers as was presented the the multi verifier presentation before. Next, please. So zooming in to the actual translations, we have SPDM measurements, certs, challenge transcripts, TDS preports, all of them map to registered claims provided by the SPDM claims set. We also have PCIe legacy config space data that map to a dedicated PCIe legacy claim set and we allow future buses like CXL, CHI, whatever comes next to get their own claim set plus, you know, that that that according to the naming rules in section five. So the point of translation is that someone has to understand what the bus actually said, and this is the lead verifier or the plugins that that talk to the lead verifier associated with each individual suba tester, but the verifier shouldn't have to, and this is the simplification that we're, you know, value proposition here. One thing to note is the translation that we are proposing is purely syntactic. There's no semantics introduced at that level. For example, we have for different SPDM measurement component type, we define aliases, but this is only about syntactic expressiveness. There's no there's no extra semantic on top of that. Next, please. Yeah. So let's barely verify. So the idea is that most verifier only need device identity and state in each form, and that's it. We allow for full bus protocol artifacts like challenge transcripts, VCA, TDS reports, so on and so forth to stay available, but they are optional. And they they are only for advanced verifiers that really, really need to consume these kind of things. Otherwise, they are erased and only the crucial information is is is transmitted. Next, please. Right. So this is probably the main value beyond pure syntax conversion. Some odd names follow a convention. For example, for SPDM, we have vendor class instance, so ACME vendor widget class zero one two point zero nine, the instance identifier that are derived from the leaf certificate SAN. And that name, let's say, receiver derive a COI environment environment directly. And from that, look up the matching reference value and endorsement and whatnot for for that exact device. So dimming here is not cosmetic. It's an, let's just say, an evidence to reference state and or state linkage primitive. So here's a, you know, there's overlap with quorum and a quorum profile for this is anticipated, but it's a separate future work is not inside this draft. Next, please. Okay. I think we can skip over this. This was addressing a comment from MCR and and we got on list. Next is what standardized. So yeah. So concretely, what we what we have in dash 10, we have the framework itself, including the outer wrapper, the extensible device claim set socket, and the extension rules in section five, which include the requirements around naming conventions for sub mods and and something else. I forgot. Anyway, and then we have completely two claim sets. We define one for SPDM, including measurements, certificates, optional challenge, VCA TD spread port, and one for PCIe legacy with minimal config space claims for these known SPDM devices. And alongside that, of course, the the corresponding IANA registration requests. And what is out of scope for now since asked, I don't remember whether in a in a on the mailing list or in a GitHub issue, we are scoping out live migration and on chip SPDM. That said, the framework is built to evolve with both bus bus technology and protocol version for a specific bus technology. So this is not meant to be exhaustive bus coverage on day one, you know, in the future people might have their own thing. Next, please. Okay. We can skip this. Thank you. Quick recap. So four things to take away. Eight, deployments are heterogeneous in terms of devices they incorporate, and, realistically, we think we'll we'll stay that way. We take a pessimistic view, but I think that's that's fair. Second, that what that gives us is a stable, right, it based convergence layer for device assignment. Third point, we have explicit sub mod naming rules to bridge smoothly to core environments. And fourth, that the framework is extensible, and we don't need to reopen the core model to add new stuff in it, which brings me to the ask. Next, please. We think this is ready. We have worked hard on this in the past twelve months, and we'd like the working group to adopt it. Thank you very much. And thanks very much to the reviewer, Gary, Carl, Yonos, Yogesh, MCR, Ned for the great feedback that made this version of is super improvement over zero nine. That's it?
[01:27:54] Ned Smith: That's it. Hey. Nobody's on the queue? We have a couple of minutes.
[01:28:05] Usama Yasasin: Can you summarize in two sentences the problem that you are trying to solve at a high level? Like, I see that you are trying to define a format. At a high level, can you say very briefly, like, what is the problem that this will solve from adoption perspective?
[01:28:28] Thomas Fossati: Yeah. So I think the the problem we are solving is the homogenization, and it was in slide three, I think. So you have all the buses that speak their own formats, and you have verifiers that want to they don't want to know about all those formats. They'd only want to know about state and identity of the devices that were attached to the to the TCB of a of a combination VM.
[01:29:02] Kathleen Moriarty: It's just a transformation.
[01:29:04] Usama Yasasin: So can I can I say that, basically, you're trying to so there are devices with different formats, and you are trying to uniformize that in some sense than that they the verifier needs to understand only one format, and that will be a transformation of all of these formats to that? Is it
[01:29:28] Thomas Fossati: Sort of. Yes. Well, no.
[01:29:34] Usama Yasasin: Okay. There is a disagreement within the office.
[01:29:39] Henk Birkholz: So the point is that this is a device, and the device is a a composite of parts that are, for example, a confidential compute component. You have a part of a CPU or you have a part of a bus. You have a part of a tensor accelerator. And all these things have to be associated in your group to form your confidential enclave. And these parts that are not devices well, effectively, you can call them devices, but we would prefer components. They speak different languages, but the verifier won't get that. So that's the translation. Okay? You can say that, but the verifier and it said some of the sites say this. The verifier do does not does not cannot be mandated to understand all these dialects of these components. That is why the debt exists. Thomas, could you clarify this as a yes or Yeah.
[01:30:39] Thomas Fossati: Yeah. Yeah. But I think that was Usama's point, isn't it?
[01:30:43] Kathleen Moriarty: Yeah. The I mean, this is not an uncommon problem to run into. Right? We're not the first to do this type of translation, transformation, whatever you wanna call it.
[01:30:57] Thomas Fossati: Absolutely.
[01:30:58] Ned Smith: Okay. We're out of time.
[01:31:03] Thomas Fossati: Okay. Any any action from the chairs?
[01:31:11] Kathleen Moriarty: Why don't we gauge interest?
[01:31:14] Mike Ounsworth: Yeah. Interest.
[01:31:15] Kathleen Moriarty: How many people have we'll we'll ask how many people have read the draft? I am. Oh, sorry. I mean, we can reflect in the minutes. Well yeah.
[01:31:46] Ned Smith: Kinda over time. Maybe we wanna take it to the list.
[01:31:50] Kathleen Moriarty: Yeah. We'll finish this quickly. So we okay. Five so far have six. So we have a good number of people who have read the draft. Well, we can take the rest of the questions to the list.
[01:32:05] Thomas Fossati: We had six reviewers on list.
[01:32:07] Kathleen Moriarty: Yep. So that's pretty good. So let me see if I end this, and then we see what is the interest in a in adopting. And, obviously, the a formal adoption would have to be big enough, and we may need more reviewers. K. So let's just do this super quick, and then we'll take it to the list. What is the interest in adopting this work? And this isn't binding. Everything goes to the list. So okay. Good. I mean, it it's pretty straightforward, the concept. Right? So I don't think it's foreign. Okay. So it's a pretty good showing. Give it one more. Alright. So we have at least 13 people interested. And, so we'll take you to the list to to confirm. And yeah. And we'll progress other work because we do have to make sure that happens.
[01:33:22] Yogesh Deshpande: I just one one comment I have. I think, Thomas, correct me if I'm wrong, but did we mention that we have commitment to implement this in version?
[01:33:33] Thomas Fossati: Yes. I I talked briefly about prototyping and yeah. Okay.
[01:33:38] Kathleen Moriarty: Wonderful. Thank you.
[01:33:41] Thomas Fossati: Yes. And the and the Linux kernel also.
[01:33:45] Kathleen Moriarty: Oh, great. So two. Okay. Excellent. Bye
[01:33:48] Paul Howard: bye.
[01:34:22] Michael Richardson: Hi. My name is Michael. If I'm too quiet, let me know. My voice is broken. Finally found a way to shut me up. So this is a collection of a few different documents about geographic, geofencing, location, proof of location, and results. Next slide, please. I apologize for the Oh,
[01:34:48] Kathleen Moriarty: sorry.
[01:34:49] Ned Smith: I can click it if you want.
[01:34:51] Michael Richardson: Thank you. Apologize for the wall of text. I would have liked to change it to some diagrams, but there wasn't time. So a lot of entities, a lot of things need some kind of a proof of environment at some level of where they are, what jurisdiction they're in, what building they're in, whether they're connected to green energy, a whole bunch of different things like that. There are many different ways of getting those results, some of which are hard, some of which are easy, some of which are insecure, some of which are good enough for the purposes of the person who is the relying party. So the goal is at no point to argue about how please never argue about whether GPS is spoofable. We all know that. But like all attack and risk benefits, you have to ask what what how much does it cost an attacker to attack me doing this and is do I care? And some cases, you do care and that's an unacceptable risk. And in other cases, it's an acceptable risk and there are many, many different ways of doing this. So don't get don't get hung up on one particular thing. So this is the goal here for this. And so the idea is that we're trying to put together the what and the where, and we're trying to express this into a common set of results. So a common so a number of different variety of inputs, essentially different kinds of evidence go into different kinds of verifiers. Verifier produces a consistent and easily evaluable result. And there's a lot of different pieces that can go into that. So since 01/25, there's the documents have gone through a couple revisions, and there's been some interactions with some other entities, including the sovereign cert group and a lot of different things. There's number of different activities, involvements, and there's still a potential, for instance, interaction with the NTP working group, specifically for things where it's good enough to know that you are within some number of meters as measured by speed of light of the in the of the electrons in the fiber. And to do that, you need good time signatures and NTP is doing that. So that's, for instance, speed of light, RGT proof of jurisdiction. So those are the different things, and the idea is that we would have a number of different documents that would produce evidence, explain how that evidence could be verifiable verified, and, you know, the the risks and benefits or security considerations of those methods. So some of those documents need to come to this working group, and some of those documents ideally would be elsewhere in other working groups. Whimsy has, I would say, schizophrenic interest in some of these things, and I don't think it fits quite in their charter at this point.
[01:38:05] Kathleen Moriarty: Agreed. So
[01:38:10] Michael Richardson: one document is this geographic results document that basically says, once you've done all the evaluation, here's a common format to put the results in. With, I would say, the most complicated part is the fact that you really do have to deal with potentially with end with exclaves of jurisdictions, and there's some good videos about weirdnesses at the Belgian Dutch border of enclaves inside enclaves inside exclaves inside exclaves inside exclaves. It's very bizarre. But, you know, that that may matter to certain entities about where exactly they are. So we're looking at the rare verifiable geofence as a looking to come to rats. The geographic results is a separate document that encodes into ER, and the VPA verifier, I would say, is is still needs to be more clearly articulated as to where it's going to belong, but I think probably this is gonna be the default location. That's really it. I think that was the last slide. Yep. No questions? Everything's crystal clear.
[01:39:28] Usama Yasasin: Not a question. It was crystal clear as you said, so thanks. I would like to raise support for this. That's a real problem. And we have shown that also in our research that, basically, the evidence from generated from any part of the world can be accepted by the verifier. And that's really a real problem because then one has to trust the whole world that all the TEEs in the whole world are secure in order to be secure. And I think this is a real problem, and we have to tackle it. I don't have a specific opinion on, this specific draft, but as a whole, I think should adopt something. And there, my question maybe is that how does this specific draft relate to I mean, there were four drafts. So have you, by yourself and with discussion with all the four, have you settled down on this as the way forward, or is it still ongoing between the authors of all the four drafts who were looking into the the location? And we also have a picture.
[01:40:32] Michael Richardson: That's why I wanted to do a picture and I didn't have a I didn't do I didn't have the time to do that. But but, yes, essentially, I would say that we are have reached after I would say we have stepped back and said, is the architecture that we had, say, in Montreal, we envisioned, is this really the correct architecture? We stepped back. And I think we'd say, having stepped forward again, the answer is yes. We can't think of another way to organize it. So, yes, there is a results, and there are ways of getting to that results. The results document is a separate document, and then there are we can argue with how many, but there are between two and three ways of of producing evidence to that result. The ways of evaluating that evidence to the extent that it needs to be standardized would be in that document. So the descriptions of the verifier activity would be in that document. The output of verifier would be in the in the geographic results, the common document, which really doesn't say much more than I could say it's a little bit more than syntactic, but it's you know, there's the the fields have semantics, but exactly how you determine that you are in the embassy of Taiwan in Downtown San Francisco is irrelevant. What matters is that you are subject to you are in Taiwanese jurisdiction, and that's what the important part is from a other from a relying party point of view. Right? That's what matters. So the there as I said, it could be two two or three documents. I think one will wind up in NTP, ultimately, and the other two will wind up here. They could be combined. I think that's open to that's fungible. Working group could decide how whether it prefers bigger, longer documents or smaller, sweeter documents. Clearly, the IETf has poor track track record at both extremes. So big documents take longer, small doc many small documents take too much people. Yep. So what is the right you know, that's up to the working group to decide, I would say.
[01:42:44] Usama Yasasin: So we we will be happy to
[01:42:45] Michael Richardson: than three, but but but probably more than one.
[01:42:50] Usama Yasasin: Yep. Camilo and I will be happy to collaborate either way. Like, in our draft, we we we can also merge it with this one or whatever or keep it separate There's
[01:43:00] Michael Richardson: there's, like, potentially 27 different ways of producing evidence, and they it may not benefit anyone to to to mix the text together. But on the other hand, their motivation and whatever, if someone says, okay. No. No. No. I wanna put the motivation for the why in one place, and then I wanna have the smallest possible text just to explain how that makes sense to me.
[01:43:25] Kathleen Moriarty: Okay. Forty seconds.
[01:43:27] Yuan Xiao: Okay. My question is that can the a tester has the the right to control the granularity of the location evidence so that because you can the the the scale can be one city, one country, one specific carrier.
[01:43:42] Michael Richardson: You're asking a question specific about the evidence to results
[01:43:46] Ned Smith: Yeah.
[01:43:47] Michael Richardson: Process. And that's why I think there's more than one way of getting there that results in the same thing. The attester could be very, I don't know what the word is, verbose about where it is. But the verifier may say, but but I don't I don't pass that information.
[01:44:10] Yuan Xiao: I think this is related to to the the the draft proposed by Mike, the privacy framework. I'm stuck here.
[01:44:17] Michael Richardson: Yeah. So so but but there's two ways of thing. A tester can just not say what a street number is, but the verifier could also say, I don't pass on the street number, for example. But now you have to trust the verifier to filter your information. But then I think that is an ongoing negotiation. Thanks.
[01:44:38] Kathleen Moriarty: Okay. Thank you for the presentation. My questions I had a couple of questions, but I'd like to follow-up after because we're out of time. Okay. Good. The questions are there was technical problems raised on this at the last meeting. So I'd like to have a conversation and understand how those are addressed on on geofencing. No. On geofencing, there was a technical consideration. I don't remember if it was Dave Thaler that raised it or Lawrence Lindblade. I believe it was one of those two. So I'd like to go through that with you and understand the boundaries. The other thing that will come up with something like geofencing is the type of constraints that government entities might use on such. So we'll have to be very careful in in how this is used, what domains it's applicable to. Right. No. But we won't put that in the draft. Right? We'll have to think carefully about what the constraints are. So I just wanted to note that.
[01:45:43] Ned Smith: So I'm gonna jump in here for just a second because we
[01:45:46] Kathleen Moriarty: Out of time.
[01:45:47] Ned Smith: We're we're kinda out of time. We we're we're five minutes into the next presentation. However, I didn't hang hang on. I didn't get a presentation submitted for the next talk. I'm looking at Michael. What what was that?
[01:46:07] Mike Ounsworth: You had the defense and geographic results. There's oh, there's together.
[01:46:12] Ned Smith: Okay. Alright. So we have more time?
[01:46:17] Mike Ounsworth: Oh, so Dave can speak.
[01:46:18] Ned Smith: So Dave can speak.
[01:46:26] Kathleen Moriarty: Good, Dave. Thank you.
[01:46:27] Dave Thaler: Hey. Thanks. So as I posted in chat the, that the draft that, Michael is asking for a document of the LKSPA Rats verifiable dual defense, does have section six point two point two on GNSS spoofing, and that was the point that I raised the last one. And so I was happy to see that there is a section on this to call out in the security considerations section about the the spoofing. And so, but, yes, thanks for addressing my comment and putting text into the document that talks about it.
[01:46:56] Kathleen Moriarty: Thank you. Great.
[01:47:19] Mike Ounsworth: The agenda ran early.
[01:47:21] Ned Smith: Yeah. It did.
[01:47:22] Mike Ounsworth: That's bad news because now there might be time for questions.
[01:47:24] Kathleen Moriarty: Yeah. We might
[01:47:26] Ned Smith: have time for questions.
[01:47:27] Mike Ounsworth: Yeah. It's it's unfortunate. Okay. I'm expecting that this one may have a fair amount of discussion. This is a document that Hannes and I, along with Hannes' master student, Giuliano, are putting forward. This is meant to be a discussion starter. So this is not meant to be a full solution. This is not meant to be us really necessarily solving anything in its OO. It's meant to put out there, do we do we have a gap in the Rats architecture, which I'm not convinced we necessarily do, but we wanna ask that question. And if we do have a gap in the RACS architecture, do we wanna do anything about it? And the answer might be no. But this is meant to spark a discussion. You happy with that framing? Yep.
[01:48:09] Kathleen Moriarty: Yep. And maybe volunteer to help solve a problem.
[01:48:13] Mike Ounsworth: Yeah. Sure. There might be a solution coming, maybe. And so first off, this is a framework. This is not proposing anything technical. This is proposing a framework in which you could design technical things, but this is in itself not a a solution. It is a framework for designing solutions. Okay. I get a clicker. You got a clicker?
[01:48:31] Ned Smith: You got a clicker.
[01:48:32] Mike Ounsworth: Oh, clicker. Okay. Core problem. Giuliano has defined this brilliant term, which is the core of his thesis, called coercive use of rats. So if you say, in what contexts could somebody force an attester to produce attestation that it probably doesn't wanna produce or that harms itself or that harms its user? And if you take that problem statement, in what and you go looking in the world for places where you could coerce an attester to a test when it really shouldn't or coerce a real a a verifier to produce an attestation result when it really shouldn't or hand those things to a party who really shouldn't have access to them. If you just start looking for things, you can find them. Yes. And the if we sort of whittle this problem down to its core, if we try and sort of academically distill this problem down, I think we can distill it down to the statement that the Rats architecture does not address the possibility of a verifier being malicious. We typically think of the verifier as the entity that is enforcing trust. They are the good guy. They are trying to find compromised devices. But nothing in the Rats architecture really asks, but what if the verifier themselves are the bad guy? And I think if you start asking this question and this could be actively or passively. Right? They could actively be the bad guy. They could be the verifier could be an attacker trying to hack a piece of hardware and using the rats channels to to aid that attack. Right? Active attacker. Or the verifier could be passive in that, like, they're producing logs that end up leaking some PII or something. Right? And I don't think either of those scenarios are really well addressed by the Rats architecture. So let's run through some simple examples. By the way, I'm gonna use the same slides at SAG on Friday. I'm also presenting this on Friday. I convinced the security ADs that this problem, while it's obviously a Rats working group problem, it has implications for other working groups who consume rats. So we're also gonna popularize this idea at SAG. Okay. Problem number one. Yeah. You've got some mobile device and some web service that, through a browser, pings it for attestation, the phone then attests itself. So I'm fun phone seven blah blah blah, and the web service says, sorry. Your manufacturer didn't pay the right licensing fees. You don't get to access this service. I think most of us will agree, generally speaking, for open good access fun human Internet should be free, this the fact that this is possible, the fact that a web service can block access to a service based on what hardware you're running, not whether you're logged in, not whether you've paid a subscription, but whether your device manufacturer is on the good list. Generally, fine in, like, an enterprise setting, but generally bad for open Internet. So part of our goal here is to give the attester more control over where and when it agrees to provide attestation. Version b of this problem is, let's say, you you have an HSM and you're trying hack the HSM and you're gonna interactively interact with rats in order to help the whatever attack you're trying to do. In this case, you know, tell me your firmware number and that tells you what CVEs you're vulnerable to. You can imagine there's various ways that rats can be used to help a local attack. Okay. So the solution to this problem, to both versions of one, is that the device should be able to say, sorry. You're not authorized to view that claim. And that nicely closes off this sort of category of things. But this is a fairly complicate there's a lot of steps involved being able to say you're not authorized to view this claim. You first need to know who's asking. And in rats, the verifier is not an authenticated role. The verifier doesn't have an identity. It doesn't have to prove who it is to the attest, generally. Right? So you need there's a bunch of prerequisites to be able to even do this. We can also talk about confidentiality of evidence. So we can talk about whether the evidence is encrypted and who it's encrypted for, whether it's encrypted purely as channel encryption over TLS, or whether it's encrypted as object encryption that stays encrypted as it passes through all the HTTP gateways, really, you think it should be encrypted all the way to the verifier. So then the verifier needs an encryption key and all that stack of stuff. And I will point out that both nine three three four and EAT allow for encrypted evidence, specifically CWT and and and JWT encryption is allowed, but it's sort of allowed in passing. I wouldn't say there's a good robust framework with solid best practice guidance for doing so. So I'd say allowed but not robustly robustly specified. So if we come to general shape of solution oh, my queue is lovely. Okay. If you come to general shape of solution, we're just following the standard CIA thing. If if we're considering that the verifier or RP could be malicious, well, then we need to confidentiality confidentiality, integrity, authenticate it. And that's it. That's the whole thing. So integrity is done. We don't you know, Rats already does integrity nicely. Confidentiality, I'd say, exists but isn't well specified. And authentication, probably not very well specified either. Probably my queue is I'm just doing I'm
[01:54:08] Kathleen Moriarty: an assessment.
[01:54:09] Ned Smith: Take it.
[01:54:09] Mike Ounsworth: So, yeah, our draft does the things you expect our draft to do, and it defines a framework in which you could define specific technologies, and the framework does what you expect. I'll leave this up and take my queue.
[01:54:21] Kathleen Moriarty: Alright. Six minutes total.
[01:54:26] Mike Ounsworth: Daniel. Hello. For next steps.
[01:54:30] Paul Howard: Let's try.
[01:54:30] Daniel Migault: So I just wanted to say that the, I've gone through the the draft. There's some, questions that, it raises regarding things like verifier trust that were interesting that I hadn't thought about before. That was like, k. Yeah. That's well motivated. I recently published a informal symbolic proof experimenting with object level encryption of evidence that is opaque to the RP that the verifier can unpack and verify that, you know, it's a privacy thing only. It doesn't affect integrity. And then I had selective disclosure. All of that worked out. So in terms of the logic and everything else, that seems to be working, and I was desperately looking for this for, like, two weeks before this showed up, so I like it a lot.
[01:55:39] Kathleen Moriarty: Okay. Each person has one minute with the response.
[01:55:47] Ned Smith: Okay. I just wanted to disagree with the premise of what you how you how you represented the the Rats architecture. We said when we created the architecture that the roles are independent of the entities upon which they are hosted. In other words, the actors are the nodes that are responsible for establishing secure access. So it's a layer underneath. The roles are composable. You can you can put different roles on different hosts, but it we're we're not it wasn't our focus to say that we're gonna define a security model all the way down the stack in terms of how an how entities discover each other and how they determine that they're gonna interact with one another.
[01:56:33] Mike Ounsworth: That's fair. And then the quick question is, should we?
[01:56:38] Ned Smith: But but the the the the premise is we we had to get the premise right before we can have the discussion. And the premise is, as stated, was something like, hey. Any any rats a tester has to interact with any rats verifier. And if the verifier asks for for something, you have to give it to them. That was not anywhere in the rats architecture.
[01:57:02] Kathleen Moriarty: Okay. Maybe consider that before your SAC presentation. Yeah. Isama less than
[01:57:06] Usama Yasasin: Very short. Less than a minute. I agree with Ned.
[01:57:10] Yogesh Deshpande: Great. Same.
[01:57:20] Yuan Xiao: My question is the incentive to to enable the privacy consideration because like like like you go to the museum, you go to some country, you ask for visa. So you need to to provide your passport, to provide you your travel experience in last ten years. You you need to go. You need to give the all some to them. So it's verified decide. It's not a test decide. So how to enable such kind of incentive
[01:57:46] Paul Howard: It it
[01:57:46] Mike Ounsworth: should it should be user decides.
[01:57:49] Yuan Xiao: For example, to appellate visa, can I say that, okay? I refuse to give my last ten years travel history? No. I cannot.
[01:57:57] Mike Ounsworth: Well, you can. You can refuse you can choose to not enter the museum.
[01:58:01] Yuan Xiao: Yeah. So so, I mean, I I I refuse to use that verify service. I refuse to connect with the ready party.
[01:58:08] Mike Ounsworth: Yep. Yeah. That is a choice you should have.
[01:58:11] Yuan Xiao: Yeah.
[01:58:12] Mike Ounsworth: And I'm not sure that the technical framework will always give that choice.
[01:58:14] Yuan Xiao: Service. So you see, this is the the incentive is important. Right? And with zero knowledge, you increase the cost. So how do you have such an incentive?
[01:58:25] Mike Ounsworth: Understood. Understood. I I understand your comment. Dave?
[01:58:31] Dave Thaler: Back on slide five, you made a comment. And if you flip back to slide five just for the context, I have a specific suggestion for how you deal with stuff in the draft, which I haven't read, so I'm only commenting on the slides. On slide five, you said that, the concept of authenticated view of claim does not exist in the rest of the day. And your voice over, you talked about there's no concept of, how the a tester gets trust in the verifier. And I think that by itself isn't true. And I think what you wanna do is you wanna split your discussion into two cases, the background check versus the passport model. In the passport model, the, a tester has a specific relationship with the verifier. Right? Just like the previous speaker says, if you're gonna apply for US passport, you're choosing to have a relationship with the US government or whatever, and so that's a priori established. And so that's one case. The other case is when you have background check-in which case the a tester has no clue who the verifier is. That's a choice made by the relying party. In that case, you're saying, I'm choosing to send stuff to the relying party, and there is, I think, the way that you phrased it is just fine. Right? And if stuff goes to a verifier that's no different from anybody else you're choosing to you choose to trust, passing your information on to somebody else that you have no knowledge about. Right? And you're either choosing to trust them and what they're gonna do with it or you're not. Right? And so I think as you split it into the discussion of those two cases, you'll end up with married with kind of different statements there because you have different trust relationships with the reliability and not the verifier itself.
[02:00:00] Mike Ounsworth: So the slides are simplified. The draft deals with we deal with the evidence case versus the attestation results case separately in the document. The slides are a bit, yeah, maybe sloppy.
[02:00:10] Kathleen Moriarty: Alright, Hank.
[02:00:11] Ned Smith: We're out of time, by the way.
[02:00:13] Henk Birkholz: Twenty seconds. Have one minute, Ned. So going back to what Dave just said, yes, the passport model is pretty safe in this case. The background model explicitly says that since evidence is merely forwarded to a trusted verifier that is explicitly stated for the background check model because of that problem, I think we at least account for that fact. In the privacy consideration for the PII, we highlight that only sending such evidence to a trusted verifier is necessary because otherwise, it would be very stupid. So that's a framework part that is missing. No. Not missing, actually. Right. Well And then for the conceptual message protection, we say that any solution should have the end to end protection, authentication, auditing before sending it. So all your concerns are literally addressed by text in RSC nine fifty four. There needs to be a solution to the problem. Of course, there's no specification that does it. And also, you start all your premise with an assumption that is on Slide one, which is an IAB statement. And that we will talk about ten to fifteen minutes about in SAG.
[02:01:26] Mike Ounsworth: Yes. I mean, this is essentially trying to expand what trusted verifier means into a whole document. Effectively, it's what
[02:01:32] Henk Birkholz: we're doing. Well, I think that is very fine.
[02:01:34] Kathleen Moriarty: Okay. Thank you. And I think this was helpful so that you can incorporate changes before SAG so that
[02:01:40] Mike Ounsworth: to start a debate, and I seem to have done that.
[02:01:44] Kathleen Moriarty: Let's let's that
[02:01:45] Ned Smith: a whole
[02:01:46] Kathleen Moriarty: My suggestion as a chair is let's frame this in a way that's helpful so that there is support and and good collegial
[02:01:56] Mike Ounsworth: work. I will take feedback from here and adjust the slides in foresight. This is great.
[02:01:59] Kathleen Moriarty: Thank you. Thank you.
[02:02:01] Kentaro Takahashi: That's right.
[02:02:03] Kathleen Moriarty: If you're offering help, frame it that way.
[02:02:06] Ned Smith: K. We're done. Alright.
[02:02:09] Kathleen Moriarty: Thank you all. We'll, schedule an interim as Ned had said, and, thank you. Get good work done.
[02:02:32] Ned Smith: Combined with the previous