Okay. Cool. All right. There goes that. Let's see what we want to do. So this thing is auto-recorded, looks like, right? Yeah. Okay. Yeah. So, is anybody else want to call? Justin. All right, great. Yeah. Hey, guys. Thanks for joining. Hi, I have Santiago here with me. Great. I'm just trying to get this screen to present working here. It's really quite easy if I did Teams, but because we're not doing Teams, it's confused. Okay. All right. I think we are in business. And there we go. This was... Okay. Oh, so you probably just need to do this. Hold on a second. Do that. Definitely fix that because I can't do that. Yeah. So it's Steve.Lasker at Microsoft.com. I got a bunch of Microsoft guests here. Aaron. Anybody else? Thanks. Did you do it? Did you just do it? Yeah. You have to submit a request by logging on to the Microsoft guest. All right. So I did create a guest account. And I put... Okay. So what's your email, Steve? Steve LAS at Microsoft. Okay. So last... I don't know how last minute this was, but thank you for doing it. Okay. I haven't come through yet. And so this is obviously you want to follow up on the... Wait, what? Roger's saying they know him. He's from Amazon, but they won't let him check in. What? Do you want to go down to the desk and get Roger to bring him up? Sure. Nia's con may also be down there if you can kill Nia's con. Nia's con and Roger. Roger. Okay. Thank you. Do you want me to come with you? All right. Do you want me to come with you? Sure. Yeah. Okay. I'm watching for the request. So anyway, so we just wanted to pick up where we left off. I think I try to put together an agenda. Obviously, just a starting point where it should all... There we go. I started putting together an agenda for us to kind of talk about one of which was I was hoping we can close down on this scenario. This is where we can start getting to the fun part of the design conversations and making sure they relate back to the scenarios. So we had to think, I think we're in pretty good shape. I talked to Justin this morning who's on the call, thankfully. And I was also taking your... Actually, there was one more scenario that actually came up a few days ago when I was having another discussion, which was around... It's a kind of... In Tato-like scenarios, a situation where the registry has built an image on behalf of someone and might want to sign that they have built it correctly from the identified build instructions. Because the question has come up with a few people recently. So there's this image on the registry, but I have no idea whether it's actually built and what it says it is or not. So you can see the docker file for the build, but you have no idea if it's really that or someone just pushed something else. Well, is there... If the registry has a build service and all the providers, like Microsoft has built it, and they're like, if I can all get out of this build service, some sort of build service should be able to potentially validate that they did actually follow the instructions and built it. And therefore, it's kind of in Tato-like use case where you're trying to say, I follow these instructions and the build, but you're not actually signing for the actual content per se. I mean, that sounds sort of equivalent to the CI system use case where you've got something that's going to do the build and maybe you've got a claim attached to it that it's the docker file or the content that you built from or something like that. Yes. So the way I was trying to... By the way, I had a good conversation with a guy from Google who does their, what do they call it, their binary authorization service. Yeah. Wilfried. Really good guy. He was trying to make it, but he was here on vacation and said he wouldn't stay married. Well, I shouldn't be recording. So he wanted to make it. I'll just put it that way. And he had some good feedback on, we're talking about identities as a whole. It was a broader set of identities, but basically one of the things we said is regardless of whether the binary itself has an identity, each system, whether it is you as Justin or the build server, it always has an identity so it can be traced back to how the thing was built or what was the entity that built it. So how is that different than what Sam was just saying, is like it's the build server. This is scenario number one. Actually, that's locally. Sorry, it's two. Yeah. So maybe try to tease a part here, which I think might be at the heart of this is there's, there's a difference between like a saying you performed a step and having someone potentially compromise the step itself or compromise the keys or other things used in this step. And I think that, that one way to do this with the scenarios to maybe like try to move forward with this would be to outline for the scenarios what happens if things go wrong in the things go wrong in different ways in that process.  You're not going to cover a case that you know, we're probably not intended to cover a case where like every crypto algorithm in the world is broken because of, I don't know, some quantum crypto plus lattice based breakthrough that happens all at once. So I think it's sort of understanding this a little better for the common scenarios and the common types of attacks. I think would be. We don't have a camera. I'm sorry. We had Justin people coming in. So I want to make sure he just repeat that now. We were also sorry. We don't have a camera because we're using zoom. I hadn't figured out how to connect the camera to it and everything. So basically you were describing the compromise key in the scenario if I understand it. Yeah. It's it's compromised keys or compromised servers or other things like this. I think just, just having those scenarios as part of what's walked through rather than a scenario saying, Oh, like Joe at the build server signed something, but explicitly having a scenario saying like Joe at the build servers key was compromised. How do we get back to it? Yeah. I think that's a good point. I think that's a good point because the difference is like, you know, having to talk through the way in which you go from a bad state where Joe has lost his key to a good state or to think about situations about, well, Joe lost his key. But what does that really mean is Joe losing his key? The same as, you know, does that just mean that, that, you know, Joe's one action might not, you know, be something like Joe lost his key to a good state or something and, you know, but still had to get validated.   I think looking at it through that lens might be helpful. Are these, well, first is that the scenario you were thinking of? Or are you talking about a different one? Yeah, that's right. I think it's probably included. Okay. Let's assume. So is it, so is this really like regardless, basically a key got compromised is kind of the issue. So anything that has been signed with it in the past and anything, because we don't necessarily know when, well, I guess maybe we do know when it was compromised or maybe there, maybe there's a debit there, but certainly anything from the date it was found to be compromised, which it might be a month ago to some future state that key should be revoked. Is that right? Yes, but it's also, but it's also a matter of how you revoke it because if there's someone who, for instance, you know, if an attacker can man in the middle all your traffic, which, which, you know, so I mean there's different keys using different places and how they're used and what happens with them. So it's all different if it's, you know, like a, you know, a key that's just used internally as part of signing something as part of a build step in your build farm. And you have artifacts. Thank you. It's just kind of weird. We're talking about security stuff and phones. Sounds like an alarm. Security issue. Okay. Okay. Just to continue. Sorry.  I guess two peas. Yeah. Okay. Okay. So sorry. So the point I was trying to make is, is that it's it matters which key is compromised where it matters what things are signed with that key, where it's used, how it's validated. And as you rightfully point out, it matters when it was compromised, but it also matters how you go from the bad state you're in when you find out that, that key which is being used currently has been compromised to getting back to a good state where that key is no longer trusted. And you have actually finished with the revocation because the, you know, the desire to want to revoke something is good, but you have to actually, you know, make it to that point in a way that ideally your users are not at risk because for instance, if you just had one key, let's just say there was the one key that Microsoft used the, the one GPG key, they used to sign everything, right? Right. Then, and someone compromised that. And that was also, you know, you didn't use HTTPS to go to download your updates. It was just, if they were signed with this key, you just trusted them. Then there's a question of how do you securely get from this key having been leaked to, you know, a situation where the key is no longer trusted because you can't just push an update with the bad key because the bad guy could have, could push an update with the bad key, right? If they can man in the middle your, your users because you're not, you're not doing anything to make that not occur. So I don't know if that makes sense. So I think that the high level from a scenario point of view is keys got compromised. One or more keys got compromised. We don't, I, we don't necessarily know the timeline. We might know a timeline. So you might be able to make some smarter decisions around that. But really the question is how do you get from, hey, everything that had this previous Microsoft cert to hear the new state of things that all those things are now re-signed and re-good in a good state. Is that basically the scenario? Yeah, that's definitely a big part of it. And how do you get clients to not trust that, to know they're not supposed to trust that key anymore from the state they're in where they currently trust the key. That's, that's in many ways often a bigger problem than just internally switching and re-signing things. So I think it, I don't think I gave it enough justice in the scenarios today, but I think there, there at least was a one point, something about a bad key or it's, it's not. So I'll make sure that we have not only this state, but what to do about revoking a key as a whole. And more importantly, the problem is we've been talking about how we can move content from these public registries to registries that don't have internet connectivity or, and they're still on a public cloud, but there's been put in a vNet that they explicitly do not have access to where the image might have started or the artifact might have started from. So we need to make sure that the scenarios we talk about, especially in the air gap state or network restricted state or whatever I called it, also have the ability to move revocation notification into that environment that kind of cover. Yeah. I think that's another tricky scenario to deal with. Like we call it the submarine scenario. We got the submarine under the water that, then you have to revoke. Yeah, exactly. Yeah. We used to use submarines and I was just saying, we used to use submarines also. And it, and the problem with that is it makes it sound much more esoteric and it's a scenario that we want to be able to take care of, but it's not a real top priority. One of the things we've just seen and I'm guessing as other registry operators have seen this as well is our, most of our customers want their environments in vNet and environments that do not have public access. So it's becoming like beyond the prototyping phase. If you get into any kind of production phase, a large majority of them are putting their production workloads into network restricted environments. So it's, that's the only downside of using the submarine snare. It sounds really cool and people want to do, but they can't. It's not really that my problem. Virtual submarines are everywhere. Yeah. Virtual submarines. Exactly. We didn't solve the virtual submarine. So Justin, I'm sorry. You started to say something else though. No, I was just going to say, no, I think that's an important, like that's one of the great things about doing the scenario exercises.  Why don't you just use GPG and TLS? And it's like, well, GPG would work in the submarine case kind of, but, you know, it doesn't give you a lot of the other properties you want. And TLS definitely may not be what you want, at least with, you know, you can't go outside to check timeliness of things using that. So, yeah, it's a great point. Okay. Okay. So, all right. So we definitely have one vote for the scenario we just described, which I've gotten the notes. Does this incorporate the one that you had put in the comments, right? A little bit. I put that more as like a sort of like a test pilot balloon sort of, you know, attempt to put one in. And I'd like to add like quite a few more where we look at compromises and problems in different areas. I think that like I said before, some of this sort of is like mildly duplicative, but it's a different view on often something that's said in another scenario, because you have to get from a bad situation to a good situation again, rather than just say, oh, we should do all these in a good situation.  And we should make sure that the damage that, you know, a bad person can cause is reduced. Okay. Do you want to, I'm happy to do one of two ways. I can incorporate this in the words that I can remember from how we do this. You can make whatever the comment that you can, I can click the button that accepts your scenario. We can do it either way. Just let me know which way you want to do it. And we'll get that one merged in. There was another, you know, from a scenario perspective, there was another section that you were, gave some good feedback that we were having discussion of whether that should move into a threat model doc. Yeah. We should definitely have a separate threat model doc because it doesn't make sense to make something. It's just, it's difficult to actually edit these things in full requests and then everything in the same doc. It's easier if there are more docs merged and then we just, we merge them. Right. I think full request against them rather than just trying to keep editing in full request is kind of horrible. Yeah. So, Justin, I'll leave that one to you also. And there's no opinion one way or the other. Just need to know to make sure we're not duplicating work and avoiding the thing getting done. If you want to make a threat model.md, you know, that, you know, a PR on that, that would be awesome. If not, we can do it here. Although I think certainly the justins, if not, Sam's and others could be better at doing threat models than what I would think about. But I think the other thing too, Justin, if you're going to open that, if you buy us toward putting less in it to start with, and then we can iterate it on it just so we can get it to work. So, so maybe something to do is like, I'm happy to have someone just take the text I proposed as a starting point. And just, just like using that as, as the, as the draft like threat model, I think that would be fine. And then we can, I mean, not a lot of texts it has. I don't know, maybe, maybe 10 lines or something. And, and I guess I wanted, while we're still on the sort of scenario separation, things like this, I also wondered if we might have a quick chat about, sorry, I'm not, if I'm going too far off topic too early, let me know, but I also thought we might have a chat about what does and doesn't belong in scenarios, because I fell into the trap that I pointed out earlier, unintentionally with, with what I was writing. And I wonder how we should set up a design from scenarios because I feel like sometimes the line gets blurred. No, that's a great point. I think it'd be good to work on something like a scope table for talking about what we want to have in this and what we want to have out of it. Is that like, I don't think I've used one of those in one of these contexts before. Can you say a little more? And I'm sorry, I don't know who's. Sorry, I just want to confirm the speaker room is there. Can you hear Sam? Good. I don't know where the microphone, I think they're up in the ceiling. Are you ready to hear us? Okay. I'm doing fine with audio. Okay. Okay. So this is Sam speaking. I'm just talking about enumerating the things that we want to have in scope or what we're talking about with notary and image signing in general and what we think is out of scope. So if we, you know, where do we feel about key distribution? For example, is it a thing that we need to figure out if it's in scope or if it's out of scope? At the risk of turning this into a full PM below the line above the line type of it. But at the same time, as we're kind of going through this process, there's going to be good ideas that are worth tracking and planning to get to at some point and things that we intend to get to that we won't and want to make this trade-off score. So, by the way, I think that's what Justin Kappos is saying though is a little different. Like what you're talking about is, like what I was trying to scope in another document with the picture, like policy management is not something we want to take on. We want to support. Key management is a little bit of a cork. I'll take Key Management out. But you know, policy management or even S-bom is something that I don't think we should take on as an S-bom here. We want to make sure we can sign S-bom just so we don't have to take the S-bom and we don't have to take the S-bom and sign S-bom just so we don't have to bet on one and overlap with the other efforts. But I think what Justin is asking is, how do we tease out what the scenario versus the technology conversation? Is that what you were suggesting, Justin? Yes, but before we switch back to that, I want to ask one thing. Is there's a goals and a non-goals like the subsections of the scenarios document, I think, if I remember right, which I think also tries to address some of the scoping issue. Is that the right place for those things or am I misremembering and there isn't actually such a thing? I think that would be good to like flesh out, maybe move into a separate document. So I think that's related to what I'm talking about in terms of scope. What do we want to do as part of this and what don't we want to do? Okay. Yeah, and Steve, thank you for bringing the conversation back. Yeah, what I was trying to say is one of the scenarios, like the error that I made when I put my scenario in is I said, you know, that when you have a repository compromised, like a repository is compromised and there's an HSM in there that has a key in it and that's also able to be used by the attacker. And I more meant that what I should have written is I should have basically said and any keys on that server, including, you know, if there happened to be an HSM or other sorts of protection or maybe even just leaving that aside, I'm kind of trying to figure out where we draw the line in terms of because in your example, I mean, so you I mean, so do you mean being able to use a key for a period of time versus being able to compromise a key? I mean, do I think in the general sense, those things are okay. I mean, those are definite files of the trap model. Hold on. Let me give a worse example of the problem that I created and maybe then you'll understand what I'm trying to say. Here's a really bad example, which is to say that that suppose a server has their local GPG key sign that they use during the you know, the Travis build that generated in total metadata and loaded this into tough, which then got read by an OPPA policy. Like, you know, so there, what I'm doing is I'm being very specific about my design of this crazy nonsensical system I just described and then proposing a problem with it. And what I'm saying is, I think for the scenarios, we're trying to leave the scenarios generic so that we're not presupposing a bunch of like, you know, an HSM or like tough in total OPPA, any of this stuff. And, you know, maybe some of those things end up in the actual design in the end, but that's not where like the scenario doesn't seem like that's where they belong. Yeah, I jumped up on the same thing initially like I had Kubernetes sprinkled on it, but I hope I'm not. And Sam kind of called me on it. So that was the major iteration I did was the generalized thing which of course spawned into, hey, we need some icons that are generalized as well so that I could represent these. So I do think we want to do it because it kind of goes back to something I wrote up, just the whole separation of concerns thing is like, we want, and that's the solution because we think that's important to the engine and scenarios. So we want to get into betting on IBM's versus Red Hat's versus the 3TS bomb versus anybody else that wants to come up with one. We want to make sure you can stick sbombs in a registry because we have a way to link things together with artifacts and they should be signed because an sbomb that's not signed is kind of meaningless. And that's kind of like the scope of what we want to take on. And then we just got to all be bringing specific technologies into the scenarios only because we're trying not to taint it in one direction or another. I do think that design conversations I mean, I think we might reference some at times for example, but even that I think we need a reference implementation and that's why even for key management I was suggesting I mean, once we've done that we're going to have to, we can get some concrete instantiations of what they were actually implying in the real world. And OVA and whoever key thing you need I think we, our reference of attention needs to be open source. I think we all would agree to that, especially if you'd like to be AWS and Azure and so on and so forth or Docker, we should make sure that anybody can validate these and then what will be interesting is when I think it was Josh actually was bringing it up, we want to make sure that the keys can be managed by a non-vendor's solution and we need to figure out what the extensibility model is for that. We shouldn't have no, do we have a key the public, sorry, the private key like invented it. We should be able to leverage those vendors solutions how we do it, I don't know. But again, that's that's a requirement that's requirements. That's requirements about um um, I mean there should be relatively straightforward because they're just like straightforward requirements about we don't need to require we won't we don't need to require signing, we won't require future and that's a private key and the I see coming out of the design sorry, the design conversations, yeah so I think just because we want to you know, just kind of move on on a base is I think we're already starting to transition to some of the design and some of the requirements part which is great. Other than this one other thing actually I won't even say one of the like this is locked at the point of being able to make new PRs if we can get this one last scenario in, do we think we're at a point where we can you know, merge that PR merge it, it's impossible to read it merging it, that's the thing so until it's merged, you can't actually really read it and decide okay, so why don't we do this, I think we it's merge what we have I think we should just merge everything we should take Justin's chunk and stick it into the another PR right, so merge what's in there already with whatever edits I think I've caught up with everybody's edits take out Justin's comments which are in the current model then we can then it's much easier to sit and read we can maybe read it now yeah, I actually did, I mean there is that view file I know still confusing because you get interrupted by the comments oh wait you know and then I can always add other scenarios or we can dump other things in there too after that there's no reason why you know this has to be the perfect thing the first time no okay, did I also hear somebody signing up to take on the threat model let me, I can just put it down there like a creative PR for the threat model so this is what I'm referring to Justin there's that view file so if you look at it here I just wanted to be in a state where everyone's the problem here is you can't see the comments I usually wanted to put that split screen set up so are you signing up for doing threat model in Montana? are you doing it now? that's good, well Justin's multi-tasking I will later on I'll merge the current one and then we'll you can do a separate PR for the other scenario and Capo did you want to do the additional PR for the additional scenario or do you want me to just write it up because you're busy with other stuff I think I can probably step in and at least take cut at some of those I'm really hoping Sam and others keep me honest in case I slip in more HSMs or things which by the way it's not that people actually use those as far as we're really aware of but I'll try to try to keep it general Santiago may pitch into the supply chain expert I'll be more than happy to take a look I've been waiting a little bit to see how things crystallize and then I'll be more than happy to jump in I don't think you have to ever worry about people jumping in and providing feedback that is definitely not their problem so we have a great group of people that are doing that Trisha can you hear us okay oh good now okay great much better thanks okay so I think we're good on scenarios I feel like we're offering ice cream now so we can get to the design conversations because there was certainly a good doc that Sam put out and we can iterate on that conversation you had some stuff you've been working on as well so do you want to finish that out do you want to I didn't want to throw you one during while you're okay you already have a threat problem I'll just put it in I thought you were doing the other one okay so now we have a threat model what do you want to do about the requirements the scenarios rather let me just merge everything and do you think you've made all the changes to I had one of the typos I got everything because I caught the stuff that Sam Sam's questions about multi-tone registry and that was the document in terms that's a different one which I have a separate agenda item I think I agree with Justin that we can just merge everything and then we can iterate on it from there we can remove things if we need to we can add things if we need to if that makes sense so I just want to keep it a little sequential just to be fair and confirm we have to get so I got the end-end scenarios in here as well so now we have the scenarios, the threat model and I'll clean up the read-me-to point make sure we keep a good table of contents on that so that's good the next one I did have the definitions in terms you had brought up some questions I did want to well we can decide whether everybody's involved in that conversation we can just cash it out let me bring that one up but before because it's also just more of a housekeeping cleaning thing what are you seeing well there's a bunch of comments or maybe we just want to merge it and then just have the discussion well to be fair I want to be careful not to because I am really bad about this I will have incomplete thoughts sometimes in my own notes and it makes reading for others really confusing I did want to make sure that we had something that people are looking at the repo and the root can make sense of it but I also want to be careful that people are reading the repo directly don't see the complete scattered mindset of where we are at I wanted to we should make a very large disclaimer in the readmeet saying that this is working progress and not to be taken as anything at this point so let's just make an action to do that okay there's a bunch of things that I think we need to very much discuss about these the things that we can't say further scenarios what I'm trying to do is also make sure we're capturing this for others that are going to listen later and look at the notes because not everybody could make it to the meeting scenarios, depth and terms and throw a bottle so I was going to go into the definition of terms next and talk about something else before I do that but do we want to just retry what's here we can do that the scenario the threat model is tiny the scenario is maybe the threat model the scenario is in the threat model let's do that kind of like assume that there's some period of time of the last something left to read it and say okay I'm going to make school readers a more careful reader, not feel bad you just make them feel bad we can see when people start typing out emails is there a pattern you hear the noise of cracking keys to be a little bit more as opposed to squirrel and keys you know they're probably chatting with someone else they're probably done I think there are some scenarios missing I'm sure and I think they're quite specific so all parts of the scenarios I mean so for example scenario number one a lake called El doesn't actually mention that the developer might be extending their build from a one to a one to a one to so it's kind of validating the base image scenario and also I think I don't know some of the it's kind of hard to read because there's quite a lot of there's quite a lot of specificity and some general it's kind of maybe what else we want to it makes it hard to see what I think the question is if we've all got different perspectives on which is perfect that's what the diversity is good about what's missing and then up to that line that it gets into a specific technology reference as opposed to the scenario I mean I think the image should be modified after it's validated before it's actually run the container is like are those scenarios we need to consider I think the scenario we're saying is once the thing is built that it gets signed well yes there's a point between it's built and signed it could be compromised it could be just as compromised the package I reference is a bad package so we're kind of saying once the signature is done that's when the trust point begins or signed it is a testing to you know Justin or build server 22 that until we do a build server 22 is bad we're going to assume the things that's put together are valid this is a question of when is it validated so how close to execution do you validate I think it's near NIAZ with that the question you're asking that is all right no it's a different one so we pulled an image we verified it's been signed and we're about to go deploy the image before it gets deployed are there scenarios where that image itself could be modified so cold versus run boundary for validation right I mean I think that's an interesting and complicated question I think the answer is that we're currently limited by the way that tooling works I think it's not with things with most of the products I'm like the things I can tell you can't give you any guarantees after unpack singularity on the other hand because it runs straight out of the unmodified image so I think that it's actually it's a more technical question and there are potential other solutions around making sure it's complicated to actually validate it after unpack with the current architecture but it's not a I think it's out of scope you said something that's interesting to me is that based on the current architecture which is like if you were working from an ideal state current architecture aside are those premises in scope for these discussions I don't think they are part of I don't think they are in scope because I think they are very runtime dependent I think it depends on whether we consider the runtime in scope for the threat models of image setting or whether it's whether it's the run times threat model itself which thing are you modeling threats on so some of this relates to how images are stored and the reasons that they are stored in a way relate to things like reducing transfer times and deduplicating data and compression and things like that so typically the artifacts that are in a registry are compressed tar balls and then they are uncompressed and assembled into some sort of union file system and the in a non-reversal transform and so the process of transforming from the compressed tar ball artifact which is the signed thing to the thing that is actually run you typically lose the ability to then revalidate that data hold on let me sorry I don't mean to I think I just cut somebody off apologies but I think this is as was pointed out this is actually more an artifact of different design solutions than a fundamental issue in the system like you can actually I mean I'm not trying to put a design in the system like you know propose a design now but I just want to point out that this whole notion of you have this compressed thing and then you go to this thing that isn't compressed but you still want to be able to validate it you can totally do that like for instance within total metadata it's not entirely like I don't think it's something that a priori we should consider this scenario to be not worth writing down I think at a minimum we should write it down and then later if we wanted to declare that this is something we're not going to handle I think we should go and then do that explicitly and say you know based on the design we came up with we decided that this particular problem was out of scope but I don't think at this stage we necessarily need to decide everything that's in or out of scope yet I think that that process you know could like the parts of it that are near the boundary I think we can whittle down later if that's amenable to others part of the reason I think it should be out of scope specifically is that one of the things that we want to do is sign generic things and therefore looking at details of whether you know what happens to those generic things often when they're being used just seems very non-generic because I mean it's like you know apps doesn't concern itself with what you do after you've installed your binary it's like it's not someone else's problem and maybe that's not a very good example but it's like we have to have if we're going to just talk about generic aspects the fact that container aspects currently have some container aspects currently have properties that are inconvenient for the validation at some point is I think and there is discussion about fixing this in other forums because it requires some design changes that are a good thing in the long run but just difficult to transition the universe onto and no one's quite agreeing exactly what the best design is I think it's just kind of not a great thing to have in scope even if we could potentially we we could potentially apply some some of the techniques we have to that problem but I think we should do it in a different space I think there's a compromise in both right so sorry I think there's a compromise in both I'll just run this quick so is that perhaps we take the best of both worlds in that document perhaps in parentheses appears to be out of scope for the moment and may warrant revisiting this at a later point in time yeah but there's something to be said about if we're only going to be focused on the current implementations today it's hard to advance the ball to a kind of a greater place with respect to you know offering integrity management over a set of artifacts more broadly answered that is true and I mean it's something that I do get questions about so now so it's like oh you had a pre-tanned answer that's well yeah I mean every six months someone emails security a doctor after this question and there are a lot of people who would like to fix that but there are an awful lot of solutions but I think one of the things that's interesting is the thing about what is the boundary like we've been there's a specific artifact type focus you know container images then there's can we deliver something out of a registry with some sense of security to an endpoint what gets done after it's delivered is that really something we're trying to worry about and I think that's kind of what we're saying it just so happens I mean maybe we do decide there is clearly demand for things that provide I mean I'm especially in the edge space security from boot to container runtime and that's an interesting problem in itself which needs put it that way I don't think it's I don't I think it's I think it's just a big set of problems that's probably out there it's kind of there is a bunch of we should have a parallel because it is something that your people are interested in so why don't we do this let's capture this that there's a conversation of is it to content delivery at which point the tar balls are delivered locally and then the Docker client in this case or the container client we want to call these things that extracts it is another problem space and then we could have a discussion of whether we consider that in scope for notary as a whole or is it you know how does container images deal with this problem because there's another topic just to grab into here is there are certain artifact types like singularity they do have a signature signing solution but we're not suggesting they should get rid of it we're saying that that's great for those types that have them they should continue to work whether they choose to put it in whatever it is that we come up with that's their choice but I think regardless of whether it's signed or not with that proprietary or that artifact specific type we can then provide another piece of signature that says hey this thing I can put in this registry would have got moved up to this other registry it's still signed with the same thing the content inside it is also signed and singularity can continue to do what it's doing well there's also issues around but they potentially have a different type of thing so I'm sorry let me seem to be careful of not trying to engineer something that maybe we're belongs in the runtime while at the same time not preventing ourselves from making that a possibility in the future to be able to letters an additional letter where there's provenance related information and data points in the manifest or something else we just need to make sure we go you know where it's possible to kind of like have those pieces in or at least not block ourselves we do so and I think as we get into the conversation we get into those areas we'll be able to kind of net that stuff out we just just make sure I added some when it belongs in the artifact specific runtime or I don't think when we start getting close to the background area we try not to kind of overreach notary into stuff that belongs in runtime but at the same time if we can we should try to not block ourselves or design ourselves into a restriction restriction does that cover what you guys were did you disagree oh yeah that sounds fine so we think we're good I have with something that's number five to take the occurrence of an attack that sounds like a threat model yeah I want to ask a more uber question around because we're neither a higher level question a threat model do we consider these the threat models that we should consider solving for as opposed to this is the threat model and this is the answer like I'm assuming this is kind of the equivalent of the threat model scenarios yeah that's what it says like inter-central network traffic that's the thing that they they can do it in front of them we're going to have an answer for these questions this is a list of threats this is not a modeling of what they need or anything like that yeah yeah sorry go ahead Justin I want to say a couple things so this isn't meant to be exhaustive I'm sure there's other things to add and it's also not necessarily intended that every single threat can occur simultaneously in like the most horrific possible way and that the system will maintain a high level of security so if an attacker goes and compromises your repository and a bunch of signing keys and a step in your software supply chain then you're probably in a lot of trouble and your users are at the moment when all hash functions have been broken yeah I think I agree with all of the scenarios but when you talk about the tech the occurrence of an attack like that's typically not something you use signatures or signing to protect against that's more sort of like auditing and looking at what's happening in your system right you yes but it sort of depends on how you I guess the way I meant it was a little bit different which is that for instance if you haven't signed something correctly like something's not signed with the right key or something else like that happens then you actually notify someone and you know it isn't you know it just sort of indicates that for instance this wasn't built on our build server right something is going on here that's I think more what I meant rather than sort of a scanning sort of thing I guess you could also like you know in that vein you could also view mitigations like you know people apply all sorts of rate limiting and exfiltration monitoring and other stuff like that but that also isn't really what I meant by mitigation so I think as long as what we do is we're clear about you know to the extent at which attacks are able to be mitigated or the damage can be reduced or we can detect what's happened or whatever else I think it maybe it's okay although I'm very happy to have this language tweet I don't know what I meant to say is that I'm not trying to presuppose a design of like a monitoring system or something else you mean yeah so my detection you mean not consuming invalid content and flagging it as something that has something had happened for example so yeah that was sort of what I had in mind but I don't necessarily think you know presupposing how that would work in a design is the best I think we might be better off just having this as a as a goal of the system and then in the end when we decide you know we're not going to build some crazy monitoring solution and if people want to have their own that's great maybe that's that's fine but then it's you know we when we see a situation where yes you should detect that in total metadata wasn't correctly signed here or you should detect that OPA scenario wasn't loaded with the correct default policy there or something like that just have those those things you know like kind of have that front of mind I so I try to digest it so one of the things is we I try to tease this out for things like the open policy you know the policy management and scanning although I didn't incorporate into the doc is our main goal is to make sure that content that comes out of registry is verifiable what people do with that information is up to them so for instance one of the reasons I was trying to make the policy management separate is we want to make sure that we can say this is definitely the mysql image by that was signed by the mysql or whatever that is and maybe mysql has different build machines so there's a subset that you could you know that's quite again that's quite specific I mean there are I mean maybe consider you know there are just very there are just very simple scenarios like I build something and I want to be sure that my cluster runs the same thing in our nation and so there's like there's very non-specific nothing about mysql or anything like I've got yeah I've I've felt more things yeah yeah engineer says it in the context of a marketplace scenario where an identity of a vendor needs to be known and validated right that's your question that was a statement I actually didn't capture the marketplace I think multiple signatures where was that actually it was the multiple signatures you could argue whether it should be better or not approved vendor project artifact so in this one I talked about I caught you trying to not reference my sql and it's acquired from some public registry again avoiding docker hub or quay or whatever and I want to know that things are signed right and then but I might want to say that particular one that version I now approve in my environment that's the second signature scenario what I was trying to tease apart separately was whether some other policy as you decide I don't allow I won't allow something from that vendor that is my db greater than version 8 that's a policy all we can all say the scope of our team is saying we're going to let you have content one of them might be an sbom which again is in our responsibility but we will verify we will guarantee that sbom is accurately signed possibly by the my db word another system can reliably read that information and make that policy it's not our problem if they determine that my db build server 12 that derives from the key has been revoked to the scenario that we need to add we need to make sure that that revocation could go in so part of the system I don't know where to put it yet can know that hey that thing was signed by this key which is now normal or valid and as opposed to how policy managers make decisions on the data that's inside the payloads there's a version control versus integrity of this thing or the authenticity authenticity of this thing I'd go higher and say policy versus integrity yeah I think we're going to validate the integrity and not enforce the policy yeah I do want to be careful here that we're meeting the goals we have of making the system usable and also secure effectively secure enough in the default sort of cases and I think maybe with the scenarios we can look at and see this because I'm not exactly sure what we're planning to leave to policy here and declare out of scope but if it's something like knowing what the valid version of you know this of like my sequel is like doing classical dependency management I think that which maybe isn't what you're saying but if that were what you're saying that I'm a little worried that we're leaving sort of so much of the problem unsolved that the resulting system isn't going to provide that we're effectively pumping the security problems out of the policy engine well what I all I'm saying is from a perspective is I don't think we can get into even knowing what a version is per se I was thinking about this last week and I think that because there was a bunch of discussion at the last call about basically that we didn't that a lot of people didn't really care at all about tags and like the names in the registry because things could be arbitrarily moved around and it was not important but I was thinking about this like the basic user case for a user building something tagging it and like wanting to make sure they're running the same thing as comes out on the end because they've put Justin's great app version 46 in a manifest file and they really want to be sure that they're running the thing that they thought it was by me that's a fundamental interface for a registry and we can't make Justin's app developer create an S-bomb for example to persuade myself that it's my app that I just pushed to a registry I really want to actually be able to get some guarantee just from the basic workflows that we actually expect with a registry and an orchestrator and a kind of flow through there so I think we've got to be careful that we're not like making we don't want to rule out scenarios where people have complicated policies but we also got to take into kind of like the basic expectations of a user and we well which is why I kind of think that we need to have a bit more thought about how mirroring works and what needs to do and what what what things are left unchanged when you mirror things and what things are changed and because basically if I if I can't really guarantee anything about my app by name when it comes out of the other end I'm literally going to be forced to put the charting process hash in and then we don't need signing but I'm also never going to be able to read anything on my manifest again and it doesn't correspond to the work thread that people actually like to use but it's a very simple thing. I literally if I have a charting process of everything I use then you have to tell me Yeah, exactly. So I think that so what you do need to actually kind of understand this kind of what is the user's expectation about things and how can we extend these to work across the kinds of scenarios that we actually want to happen and that actually people use as well like mirroring and moving things around and things which don't work now at all either but we need to kind of do it without requiring everyone to add an S-bomb to all content which is never going to happen. No, I agree. So I want to be really careful we should absolutely have the verifiable thing that we talked about without enforcing a policy to be part of our course now we should not require an S-bomb that we're not even taking dependency on a specific one to meet our initial goal. I think the question that is a great one is the name and this is actually why in the definition of terms I think the artifact is a separate name because I think the name of something that might be colon B2, let's just say where I move that across a repo or a registry I need to know if that's still the same thing you're making a good argument that I shouldn't be able to I shouldn't know what by its name and separating the path which one we want to call it because I don't really care but the point is that I think you're trying to make we all agree that the path and the registry should not be part of the signature point we never registries confuse location and content but conceptually people do think of I think you have a mental model of some kind of canonical name or something or we need to be able to provide a way of them so I mean it could either be some sort of I mean it could be I don't think it I don't think it's I mean you know the visual image is a thing that people have a mental model of and we want to be on path there in lots of places and people can be sure they're getting the same. I want its reference in the from statement we want to make sure that it is still the open to so I for the person that I don't know if anybody else was pushing with me I was pushing back the most on having the repo sort of the artifact and the tag be renewable I think I'm kind of pivoting back on that as long as the actual last node and the tag is the only thing we're saying that's what we are saying I don't agree with that at all which part making any part of the name not okay okay then how do I know that my I think we need some sort of notion of example name that is divorced from the location which is which is different from saying that I take the existing image name which today is the location and you know I think that I mean my thinking was that for example say SQL Server would have a canonical layer of Microsoft.com slash Windows slash SQL Server which would be unrelated to where you might get from ACR in some region which might have all sorts of different addresses but you would but it would be as the name that you would be validating yeah I think we need two different things we need one which is the location and one which is a name that you're validating and we shouldn't try to use the same thing for both of them okay so I think we're talking about whether the name I just I brought up the doc that we were kind of I was trying to tease out some of these things so in this case I'm calling in fact being the last piece that would be the MySQL colon V2 that's just the tiny name space but it really allows me to move things because it's too small so I was well but it allows me to do this I was trying to find the balance of what I put in that versus this larger conversation so the problem is here's what customers wind up doing we're going to do that here I could take like here is where it's starting out I have teams I have a dev brand I have a dev namespace that has a red team and a blue team and they've got web API and a batch process of these teams got a web API and a queue manager and then there's a staging environment to the same registry and there's a prod environment the same registry and they're only designated out by path and whether it's two or three or n namespaces which is just slashes are special characters is not really important they can do dashes as well so the point that I'm making here is that these teams can move like this dev team took their web image and this is the thing that I'm suggesting is we have a way to sign that piece and when I move it to the staging environment and the marketing group and then it moves into prod and then eventually moves into an archive location that signature moved with it and the name is the name so I think what we're debating is everything to the left of it is not part of signature so I can move them that name is just as well I mean literally everyone calls that thing the same thing but would they be signed with the same key and maybe you're making an argument for what Sam was proposing it's actually an element in the manifest I think it should be two separate things and not try to reuse the location to determine the name of it so what do you determine locations of fully qualified name or what is the image name today doesn't have anything to do with the content of the image whatsoever it only has anything to do with the location so if you leave it that way and then you add something to it that has this is a field which I'm putting whatever content into it that says this is what I believe my canonical name is and I sign that with the key you can say that I trust Sam's key and whatever Sam's key says that this thing is I'm going to validate that or you could say I'm only going to trust Sam's key for things that Sam is identifying in a particular qualified name space or something like that How do you like height? I think the location is different from the you locate the object with what we have as the image name today which is What does validating the name give you though? It's not just validating I think you're saying the name is part of the value I can look at that name and the mutable thing that is when I see the signature the name here we go this is what I was looking for I'm saying that the name is basically a claim that is signed with the signing and so you're able to validate that as part of the content when you're validating the signature it's already within the signature it doesn't have anything to do with where you pull it from right? I wanted to rename this thing over here I feel that you've signed I'm going to claim that this is my name So that would allow me to for some people they actually re-tag your stuff I didn't put that example here so this will be 1.0-deb then it will be renamed 1.0-prod So that what Sam's proposing would allow that what Justin's suggesting is that name you couldn't re-name the tag so I think it's the flexibility of both I think what you're proposing basically is imposing a workflow on people you're saying that only this workflow is the thing that's going to be supported as the existing tooling for how we deal with container images today does not influence a particular workflow well to make fair the workflow is broken in particular so find a solution so I just wanted to say that if we think that this renaming and moving of things is part of what should be happening then I think making a scenario that explains this and explains why you need this and what it does at least for me it's all a lot clearer if we think it's important we do think it's important there is a scenario but I don't think it's very clearly explained familiar I mean I think that it's it comes from what actually happens in practice because there are I mean roughly there are now I guess when we started naturey there was really only one registry and now there are a very large number of registries and most people use multiple registries people have invented workflows around promotion I think which are maybe not very good ideally but they exist they are doing a model because of their design but fundamentally people run registries locally in production as a pull through cash people run registries on edge devices on submarines people run registries in every cloud region that they are running content because it's local to their regions that they don't pay exit fees people run registries several registries for like get-out actions as their own registry and get-out for when you're building stuff but it may not be the registry used for production so the movement thing comes from the fact that it's very real and the naming issue has become a problem because you basically can't validate content between these things except by cash right and so that really covers this case because scenario like this idea of movement I definitely agree it's not very well written if you're not familiar with I think it's too detailed and too generic enough as a description and it doesn't kind of explain why people are doing this and what kind of things what the expectations are either I think I was going to try and just write a separate document just explaining what the mirroring situation is and why it's kind of I don't know what would be most useful isn't it because I think it is definitely one of the most important driving requirements that happen because of the change in how usage has changed over the last five years as it goes from registry to registry to just have them re-signed what expectation is there for a nested signature or re-signed you can't you don't want to re-sign because you don't some of the inferences are not particularly trustworthy at all some of them are ah sorry for those of you in the community the classic problem is we ship our software company as well as the cloud we want windows sql.net and dynamic CRM to be able to run in AWS but it should be run in your registry because it's closer to where your deployment is as soon as somebody pulls it out of MCR and puts it in any other registry we know our own signatures are lost there's no verification what am I going to force you to re-sign our content who are you going to sign our content what does that trust provide and in the IoT case we have the same thing like we have certain customers that don't have these nested secure environments so they want to move their IoT image and maybe they get it from us or they get it from the third party and as soon as they bring it into their environment the signature doesn't mean anything anymore so I I would the question is this is a great sorry go ahead Joseph I think this is a great scenario to add because I would argue if we were if we were talking about design which I think it's premature to do I'd argue that you should keep the old signature and have a a new signature for the new registry too whereas I think this concept of just checking the old one is fine too but I think you actually get advantages like if you can have a design that does both I think that gives you the best solution so this is I don't want to fight that battle now I just want to say that no no no I'm going to point out to you you guys what advantages there might be and yeah so so if you just have one or the other signature then I think you have problems that you don't know if it's blessed by both parties which is really what you want to know and so yeah but I'm also leery that we're kind of probably reaching close to the end of this meeting at least I have to go in eight minutes and I don't want to I don't want to derail it I just want to say that I think that the way for us to move forward and have this discussion is probably by having a really clear scenario with it and then going through and then you know we can quibble about what the advantages are to having both or just replacing one or leaving the old one and not having the new one or so on so I do believe that the next covers the scenario I think it just needs to be rewriting which I think I think I think we should take it I think we should take it go to the rewriting region yeah that's what the PR is about give me some feedback on what they want to redo about it because I think the scenario that Kapos is referring to is I think what Justin Cromack here is kind of reiterating is what I was suggesting is you shouldn't have to re-sign it just to know that it is still the same image from the artifact from that vendor the question that whether I want to say I have a secondary signature that says just because it came from Microsoft doesn't mean I want it in my proud environment the old version that they shipped last month that one I'm perfectly fine with I've tested it I'm allowing that in production the new one that just came out yesterday I haven't run my tests on it yet I don't trust it yet so I trust that it came from Microsoft but in this scenario 6 1 and 2 I talked about until what was in Acme Rockets or whatever it was a test does the signing sorry does the testing and then signs it specifically for the Acme Rockets product environment it's not allowed to be moved into it so I think there's a test for both yeah I was kind of thinking along those lines like the whole promotion scenario Build Server goes and signs the image goes to almost the staging area that stands and whatever else then it's actually let to go but the challenge is if you re-sign it when it goes from that staging product does it imply now that it's been re-verified but not if you're intending to trust the Build Server how is it that you can still infer that it wasn't got that forward a couple of years or whatever how can you infer or in other scenarios that that actually wasn't modified in any way shape or form if you're re-signing it oh I am suggesting that it's an additional key the first key isn't invalidated so you could say I only trust things that have and it has to be from Microsoft those are key as trust and the Acme Erotic so this way that the first signature is still valid because the content didn't change I just put another stamp on top of it that says this signed content is now also approved in my environment now gets a little interesting is when the S-bomb does there's an interesting S-bomb scenarios where they do want to add some other metadata and they want to have that signed as well and that's where I kind of think of the S-bomb stuff is good the S-bomb have the concept of hierarchy so here's my S-bomb and here's the S-bomb from where it came from they're both signatures but those separately signed things I don't think we need that for the core scenario what we're trying to do but if you need to know hey this test environment who did what in that test environment was it tested with what binaries those I think I think let's clarify this I had to take back my time because in that case there's actually another implied level of trust related to the additional activity that happened in that staging environment that really wouldn't necessitate another signature because it's not often time to go into fraud in the case of fraud it's not just to come from that filter but did this work well it takes place and was signed at the end of that too but that's very well but are you suggesting it's just an integration test or you're saying there's something else I don't I'm trying to tease out if there's like the nuance between like say taking other activity and there's implied level of trust that comes with that in addition to the initial signing versus simply moving something from one place to another so they should be divorced right if I'm going to make an assertion I need some key to make an assertion so if I'm saying that this has been tested or if I want to change the name to something that should be trusted in policy I need to sign whatever I'm putting in versus some developer just saying like I want to rename this to make it easier for me to understand we're not necessarily validating that assertion yeah no but like if I could say that right meaning you can sign it and that could be your attestation the signature is that but we shouldn't necessarily make it that if you're renaming it it needs to generate a new signature right like if I move that was I was the location is different from location filing whatever we change like shouldn't affect it it's only the assertions that you make well that was the conversation that we had about like the actual user expectation is to some extent that what you because the registry is a file system that you don't expect to modify as file names in the middle because it is designed to be some names that might seem usable but generally you do expect things to not be renamed and that well the current signature flow does but that's what I was trying to tease out in the definition terms is if we can say the thing at the end the right is the name and not suggesting we agree with them so that was part of what I was trying to tease out versus the path in registry then we at least we can say this thing that wherever it flows is still whether we're signing whether we're attesting to the actual name in the last element or it's a piece of metadata inside of the payload there is a thing that can move and it's always signed is there some other way to verify besides the signature where this comes from do you care where it came from if you do like could you use some other mechanism is what I'm trying to get at because I don't think the signature is the right way to verify that because signatures are a method of assertion and validating these assertions and location could or could not be an assertion so if you decide to set up some other mechanism we don't want it to be the location but potentially we want it to be the name that's what I'm saying but to your point what is the name because everybody has web version 11 so what exact now maybe it's web 11 but the signature is from foo vs. bar but to be fair I think from a scenario point of view maybe I'm trying to figure out how do we transition from let's wrap up the scenario and move into how do we design some list because I think there's some proposals on some of that I think the question that I'd love for us to kind of come to conclusion on and then we just don't come to conclusion yet we come back to this is what is in a name what we define is the name and I tend to lead to what you're saying is that there's a way to put it outside of it and I can enable workflows that I rename the tag for instance I'm just struggling a little bit because honestly as far as our own naming at the end if you like I realized this when I wrote this blog post yesterday one of the things we did with the Microsoft images was we used the favorite hierarchy to represent products whereas those windows images so our .NET and windows images as well as a lot of like sequence of other products we actually use here it is so .NET core runtime is runtime v8 v3 what I'm proposing right now is the last thing the artifact name would be runtime colon v3 what runtime we purposely use this .NET core runtime structure so I'm not following my own that's what I was talking about it was a particular workflow agreed so that's why I'm struggling a little bit with where do we find the thing that I'm signing because I don't want to have to go back to digest I shouldn't be able to look at it you can't even retrieve anything from registry by digest without the path yeah yeah in the registry we store those digest separately and you can move it around but you're right the docker pool command does need to if I move that same artifact between two repos the digest is still the same you have to know where it is I don't think we're saying at any one point when I recall it I have to provide the path because that is where it is and it's the same thing whether I have a binary I like to reference the old MSI on a network share I need to know where I'm getting it from at the end of the day I don't really care that I got it from there I want to know that office.msi is still the same office MSI or take the thing that you're going to be selling the machine you're worried about but I shouldn't really know where I got it from but to get it I do need to know the path it's just right now the workflow combines those things if I say npm get I separately configure what npm registry I get it from today with the way the docker flows are I'm encompassing the entire path into it in fact that's kind of what I put at the end here I made some comments around should the artifact reference include the registry it would be nice to go back in time or do a massive breaking change that's about as much as we can do you snuck out do we want to take a break I think Justin was dropping off at 3.30 anyway when we take a 10 minute break we'll be back at 3.45 specific time and I also have a conflict in 15 minutes I just wanted to point out that Tushank and I are going to work this week and try to come up with some context for CNAP in the V2 discussion we're going through the proposal and design and hope we can give some relevant feedback and scenarios that we've encountered when talking about signatures in CNAP with customers excellent thanks okay so let's take a break see is there coffee? I remember you saying I'll show where the coffees are in the bathroom the two primary coffees so the trick here is yeah hey guys sorry I just stepped away for a moment everyone taking a break yeah people already taking a break perfect thank you thank you pleasant to dream I've been running all over the place can you see all the second floor? just I'm never at my desk following the car building it's a little bit like the New York subway because some of the floors you have to go down to another floor to like transfer to get to another floor what happens when you have a high rise though I mean couldn't they just have all the elevators like two banks they're going to all the floors every high rise I've worked in has been like that with transferring floors yeah I guess so I mean they try to yeah that is true I think we should have the next one at 80 minutes again because we've got mostly eight people we've invaded people move yeah I don't know what happens they don't they have their own solution they have the station I thought Omar had actually spoken with them somewhat recently like a couple weeks ago yeah I think so that's where you do all the papers as well when you say the activation it's really inside right in the back here yeah actually inside the manifest but it's not really intact no the signature is by reference so the signature has a digest and then it's the other thing you can go get oh the signature is not in the document right yeah it's not in the document but then if you have another signature then the digest will change the digest the index will change but not the digest and the manifest it's one of the things that we when we get closer to deciding the implementation things we'll have to pay attention to one thing I just wanted to write off different possible ways that it could be there not that any of these are a way that we actually should go and let anything I think the one thing that was kind of interesting with the Trump model the last one with respect to notifications as well as the alerting if you will is just ensuring that the data is available in some way that it could be consumed by wherever this has been implemented whatever notification system they have has very detailed on the events so that the whole sequence of events can be maintained and can be brief ordered potentially maybe not but just making sure all the data is exposed in a way that we can consume in other types of systems that would be meant for like event tracking notifications etc just really confused with that there was a line in here that referred to like yeah but that was the misunderstanding yeah that was a misunderstanding that was the intent of it was really more just having it exposed in a consumable fashion that should be handed off to another system no no no but you being able to tell that you would use a compromised content you would detect how it has been compromised which would be apparent it would just be apparent rather than yeah I mean which is kind of obvious yeah yeah between index and manifesto and this between nest there are just list and index are roughly the same thing it's just manifest list is the buffer term and index is the OCA term and I think the terminology has always been a bit confusing for those things because I think I mean yeah I think because manifesto all those tools called manifesto yeah I think maybe the terminology is I can't remember but did the change on it out of it anyway I think it was talk about well the term in the OCA is index and I don't know how that got I don't know the history of why I just know that that's what it is there in the index in the in the Docker registry it's manifesto what else do we have an agenda that we had on the original so we had definitions and terms which were actually might be relatively interesting and we were talking about naming and then we started getting some design discussions which was led by the so it did design discussions period I'm already trying to jump into some conversation so I think I think I know I was I know which PR I know the PR I don't remember no it wasn't it's someone possibly from IBM he was doing that working on that PR I don't know they're on the call as well they're not on the call I can't I mentally can associate the person if I saw I I was to be fair I was putting stuff in there and people weren't really sure if it was the right thing to talk about I definitely wanted to get to I don't think it's the right thing to do right now because I think it's further down the road because it's quite specific and from the use case point of view we all know that we want to support remote key services that's very much a requirement I don't think so I don't think that we're going to actually I don't think that we I don't think it's likely that we're going to get transport for that because I think people are going to use that but I think there is I mean we've actually been it is it is a useful thing to have transport from there we have with our being with numerous project which actually does have a transport for key services which is quite generic which could do with which is a local transport but could do with a transport so I would be I'll I can reply to I can I can say that Justin is and that's okay I didn't think it's okay because it's quite specific so I think there is something you just said maybe we should document this is that key management there is some expectation there will be a variety key management system, and support for private keys, I think. I think we said we need the public keys. In terms of the what's in scope, we need to, I think, probably write a what's in scope, and design stuff. Yeah, because I think that where keys are stored and how they're, how are you writing which is not really in scope, but usability aspects of key distribution are very much in scope. What do users do when they lose access to keys? How many keys do people have to trust? How do people get hold of the public keys that they need to trust? Those kinds of questions because a lot of the usability issues are generally around the fact that there are too many keys and it's difficult to design reasons. There are way too many keys. So I think there's another way that it sounded as if you were about to specify a number, like in response to that, you're about to say the limit is five or, you know, but then I just fraught with, no, no, I wasn't going to say, no, but it's going to be like, I mean, the current nursery situation is effectively you need a key for, you need to know the root key for every rebate you want to access, i.e. for every piece of software you want to access, which is way too many keys. There was a question. Because, I mean, they were potentially to be written in the bank, but because we didn't use any IRF, you couldn't even trust a Microsoft key. You have to trust the button on or at the end of the order. Oh, okay, right. But the real problem is the chaining, like the problem was, it was the fact that it was just hard to use, right? If you happen to, sorry, I'm just trying to ask you a question. Just the right conversation we want to have. The good conversation, we, I think we started by saying we didn't want to talk about this thing, we weren't going to talk about it. Hey, this is what we didn't want to talk about. I would love to get a, at least in a further conversation on the meaning thing and what we're signing thing, because I think that's a little bit of what you were got in your design conversation. There's another piece of the design proposal one, where some of these elements are stored, which I think can potentially come later. But I think the really important part is what are we attesting to and what do we want to kind of guarantee? I'm not not arguing this thing, whether it's an annotation or a new name to element, but what is in a name and what are we saying is the thing, what is it you're defining is signed and verifiable? I feel like that's the piece that's still left. Regardless of how we write the scenarios discussed, that's the gnarly one that's still left open. Sorry, go ahead. Yeah, go ahead. Oh, I was going to say sorry. It's a little hard to hear, so I don't know if I heard everything. This is Kieran on the phone. It sounds like we're saying for the the gRPC stuff that it's too, we're too early for that we're more on the design stages, which sounds fair. I didn't hear everything that was stated. I just wanted to quickly voice in on that. I know part of the concerns. I'm sorry, what was that? Kieran, was that your comment? It was my comment in the Slack. It's not my PR. It's another company's PR. But the concern that comes from all of our companies, there's a few of few of us companies actually on this, the concern was a couple things and it was more in the implementation. So one was that it was kind of built into Notary that Notary would create keys and software, at least for some of the types of keys as opposed and it did, I believe, what was called like ad key as opposed to actually creating the key. So even if we use the PKCS11 integration and don't quote me on which keys these were, but I believe only the root could be created in the in the HSM and the rest were not. And that was problematic. The other thing was the ability to use existing keys. A lot of in the enterprises, we end up having the administrative side create the keys, so we don't want necessarily the signing tool generating those keys on our behalf. So again, I know that's early, we're probably not there yet, but that's really the voice. It doesn't have to be GRPC. Dave did a great job implementing that, but it doesn't have to be the GRPC implementation, but something that allows that flexibility for the keys in the back end.  And so the ability to integrate with those in an abstract manner would be great. I think we captured that in a scenario because it wasn't in one of the scenarios that I listed that I read. So adding another scenario for that because we see local signing for local keys, a PKCS through any kind of transport would potentially address that. And that's probably a design decision that we are implementing. Yeah, I think if the requirements need more clarification on anything, I think we want to have a separate requirement stock, for example, we have a separate threat model, and I was going to capture things like the key management solutions. If we do need it, maybe have an HSM kind of solution requirement. I don't know, it makes me nervous because I don't know how you float hardware keys in a cloud, but... Well, I do. You've got an API for it in your cloud. And they got one in their cloud too. Do I really? You do, yeah. How do you do hardware? Okay. But I think that... Are really hardware-backed keys that there's an API that's in the hardware key up? Yes. It doesn't send you the key. No, it just sends a sign in. Okay. Anyway, this is why you guys are here and I'll focus on one scenario. But yeah, I mean, capture the requirements. But I think, yeah, the question of what the APIs are is definitely out of scale at this point because we know that we're changing a bunch of the design decisions around how the actual service architecture is. And those are the bits where actually all these decisions will mix, although it's kind of going to be... So one thing was that... This is the reason that I previously put a comment in your public request about that, talking about keys and having keys in a certain place. And rather than having that, if we could just sign this, so that would make it more accessible. Yeah, definitely that's the wording we should have. Yeah, I mean, be signing and the key doesn't have to be there for you to produce the thing. Oh, I was trying to be explicitly saying that the key does not have to be in where the key comes from. It's in part of scope, but I almost pivoted too far. It sounds like... Okay. But then again, I could be able to clarify wording or issues to clarify wording. That's what things say. Just make sure that everything's captured. All right, so let's... I think we're going to move on to this one. This could be a follow-up discussion as well. You mentioned something about the key hierarchy being sort of problematic. Should we have a conversation and have this offline afterwards about key and certificates and how we envision them, like what the challenges were. We'd like to understand a little bit better. This PK management gets pretty gnarly, and I think there's trade-offs on both sides, but sticking to just keys also just increases your blast radius. So I'd be curious to know what the challenges were and if there's scope for addressing that at this implementation. Yeah, I think we should have that conversation, probably not say. Yeah, I created a parking lot for this, so we can capture some of the things we want to compare. Yeah, definitely. And I think not also partly because it kind of... There's an interplay between naming and PKI and that kind of thing. But until we we may have to iterate across, you know, between what we're doing with understanding the actual... I was just asking, connect those two dots, so you were saying that naming constructs, naming decision is closely related to the PKI? It might be. I mean, maybe or maybe not. I mean, I think sometimes you've got to attach keys to names and we have to understand that, but we don't understand what names are. I think that's kind of a bad thing, but we're trying to... I'm trying to... And in this case, we're talking about names of the container, not names of the... Not yet the idea of the signer. Those are separate names. No, but you're saying you're talking about names of the container. Well, that's the thing, they might be... Yeah, sorry, yes. Okay, yeah. Yes. Probably a good pause point. Where do we want to go with this? It seems like naming is a piece. Is there something else you want to discuss? Do we want to kind of figure out what we want to do about how we're signing a name or where we want to pivot this conversation at this point? I'm kind of curious if we have other similar naming versus location things that we should be comparing against or how we do the naming, because... And also what we think... I mean, if we were designing this thing from scratch, I guess, why would we... Including the registry? What are you saying, design discovery? You're even saying the naming thing. The naming of containers. What would we actually... I mean, would you want to separate... If you want to separate locations from content in a reasonable way, what other examples have we got to look at? I was trying this idea a little bit. I mean, the NPMs, the package managers of the world, there's an interesting one. I have a great little namespace, generally. And that was the thing I wrote. It's like, the package managers aren't your end artifacts.  But when I have one of the fundamental things that I was supposed to talk about, containers or any deployable artifact, is I wind up with a thing. I don't want to be able to move that thing in different... Like, I need to move it from public place to a private place. I need to be able to move it between environments and people moving between environments in different ways. And that's different than an NPM or any kind of package manager component that I pull into an app. You can set your Debian mirror for any location you want. You could. And you get your... I mean, so, from the back of my view, it's very much location independent, but there is a global namespace for Debian. There's a global namespace. There's also a set of keys. So, Debian in particular has a Debian keyring, which is installed on a Debian system. And it's used to verify the packages that are installed from a valid Debian mirror. You can also add your own keys for additional repositories like that. But yeah, there's a single global namespace and a single set of keys. And well, it's true that you have different ones, but they're not as fluid as a final thing that you're trying to manage. Because one of the things is when we get the Professor of Industry, which is there, coming up, it's the last one. I don't know, it doesn't belong to the top one as well. No, I know, but it's still part of... I mean, it's like... But one of the things that one of the features we had discussed around mirroring was basically having social host support on it, so that you could just... You could request docker.io slash library slash Ubuntu from... The proxy from... Not a proxy. Just directly from a registry which would support nspace content. Talk to you a little bit more. So you require... You... So I'm in an isolated environment. I just imagine there's an HTTP server in another registry, and it's just a virtual host. And you just configure a virtual host for docker.io on your registry server. Oh, so we can respond the content in it that it can respond to. And you just change the file so that you can just say use this server for docker.io. Are you talking about content being pulled through, or are you talking about content being replaced in... What do you mean by... I mean, it could be either. It could either be a pull through cache, which... I think we did have support for anyway. And that's it, isn't it? No, I think we had this unique to DTRH. Well, normal registry has a pull through. But I think those registry has a pull through cache support. I mean, a pull through cache support. But it only goes to docker.hub. Like, I can't do a pull through cache to acr, acr. Any of you? I remember on this conversation we couldn't... Anyway, but generally, you can actually... Imagine you could just push content there and say this is docker.io slash... Well, I'd be such a bling to Dan in this registry. It's a pressure. It's a pressure. Well, what are we trying to... I mean, they're trying to... They're trying to sound like the old Red Hat or a class that got... No, no, no. Well, no, I'm just saying that this is one approach. I'm not suggesting this is going to do anything. I think it does it. But I'm just saying it's one approach to separating out and naming it. So you basically make the naming separate from location in the way the virtual hosts do. Oh, the name is still the name. You didn't really... All you did was redirect. You basically did a host entry in a weird way. In a better way. Well, you read it because it's still the same unique name. It doesn't really help me when I do want to reference it as a separate location because I want it to come from... No, it doesn't... Yeah, it doesn't change. It doesn't change that case. Unless your registry gives you a brand-one redirect or something, they can you configure it to say... And then the other problem is just uses the Windows case. You know, Windows images, it's just... Because a new version of a particular tag came out, doesn't mean I want it. Like, I want to test it first. It's like the Windows software update service. Our laptops individually might get updates directly from Microsoft. But inside the enterprise, the enterprise controls that update. So, you don't really want the pull-through updates in that case. But that wasn't just a pull-through. I was just talking about naming. But even the naming in that case, because like the... Some of the things do get updatable tags because we want them to flow through another thing that's our unique tag. So, I guess I'm trying to understand what... I'm just talking about mechanisms that separate naming from location, given where we are there. Like, I'm just trying to find out what kind of things would people consider... What kind of changes would we consider to be potentially reasonable or unreasonable if we want to make these changes without... I mean, you're suggesting that basically having a name that's signed basically means that if I want to retrieve something, I announce provide two names. Yes. Which is a big change to use.  One is where you're getting the content. And the other one is this is the thing that I'm trying to validate. Yeah. And so, that's a big user change. It is. Yeah. I just want to explore the kind of changes we offer that are not the chance to manage it. Yeah. I didn't quite get the lead that the pull, the Docker pull equivalent changes. That's what I just heard you say, though. Well, I'm not proposing anything in particular about a workflow. I'm trying to keep workflow out of it in that I don't want to force people to go into a particular way of naming things or a particular way of organizing their storage or anything like that. But if you want to say, I want to retrieve it from some location and then I'm expecting this to be my SQL 5.6, then I need a way to say, I expect this to be my SQL 5.6, and it's stored over there. And so then I get it, and I say, this is an interesting one about a thing that's there, and does that validate or not? But that's a, it's a policy. Yes. Yeah. So it's a policy configuration. So it's not necessarily something you're pulling into Docker pull to change your workflow. But in my opinion, it is because of how Docker pull images, which is sort of, sure, the implementation of Docker pull could change, but when you're configuring your policy, you're configuring your trust store, that's a one-time action that says, I trust Microsoft and I trust anything that's naming my SQL, right? Are you specifically every time having to re-specify? Because the implementation that it took today would do a Docker pull based on the file name. That's the same. It's really the policy you can figure that says, this is what I trust, which is the separate action from Docker pull. Right? That's something you're doing. You're doing great. But then, so one way that this could work is Docker pull goes and retrieves the image from whatever location you specify, and then basically Docker inspect exposes the fields that were validated on pull. And so one of those could be the name that is embedded in the claim on the signature that says, this is my SQL 5.6. And then outside of Docker, I can inspect that image and say, oh, yes, Docker validated that that is the name that I expected it to be, and I can go ahead and watch a container from that. But at some point, the way you said, you have to express two elements. What do you do somehow? You do somehow. If the name and the content, sorry, if the content and the location are two different things, which I'm asserting that they are, and you want to search on the content, not just the location you have to specify both. I mean, there are ways of kind of hiding that. You can define where you want to get things from in a config file based on the mapping from that name. Right. Then just pull that by name. Which is roughly how it works. It really can be like a devian software repository work. Yeah. Yeah. So yeah. It has sort of a templated way of I take the name that I expect, and then I go find that based on how the repository is configured and I ask configuration files. Yeah. Yeah. Although Steve at least would like it to be more complicated, and that's the thing if you want to do the devian list directly. I never argue for more complicated ones. That's right. Steve wants to change the directory. OK, just maybe. Whereas the kind of devian mirrors that they all have the same, they might start at a different base, but they all have the same directory there. Yeah. You want to move your content to somewhere in a different directory out with a different file. Yeah. Which makes the config side of this, like expressing a config for how you want to do this. Very difficult. So it would be easier just to specify both names because the config is in a config file that's going to be ready to render. Basically the existing registry distribution ecosystem has exposed location as a thing that people can customize. Like very detailed level of this is the registry that I'm putting in and inside that registry, this is the repository. And this is a dev region. And very specific of where the location is. And so people have done that. And that's now part of their workflow. Yeah. Yeah. I mean one of the biggest, we pushed against some registry permissions that's for a long time for a bunch of reasons. And it's been the highest requested feature that we've had was like they want repo level permissions for different teams sharing the same registry and different environments accessing the same registry. So I don't know how to treat them as a flat namespace, so to speak, that you have to have another registry then to move it to another environment. Like just separating out the registry name, I think it's probably going to get more past that point. I don't know if we can do that again. Well then, so if you take the case of Debian, Debian doesn't require a different registry name, it requires a registry name and base path effectively. And then it appends everything onto there. Oh, so you really just trained them about different right in the team. So you can map, you can map docker.io slash library slash Ubuntu to ATR slash docker library slash, slash docker slash library slash. But does the Debian image itself also have slashes in it? Or is it only? Well, we're not saying about the Debian image. They happen to have a, well, the repo is a set tree of files. Yeah. The package names, they have slashes, but the class you get in the repo. Package names don't have slashes and it's a flat namespace. And if you have multiple repositories that supply the same packaged name. It's not twice as flat namespace because Ubuntu and Debian are effectively different namespaces. They're not stored in the same places. No, exactly. They're more like different registries. Yeah. But they store the same. Exactly. You've got the left side of changes here. But you don't have, but you don't need to finish. You really should not mix them. But yeah, in the main registry, there's no, in fact, we're going further to mix them. Yeah. What I was getting at is, like, assuming that you have an installation of Debian and you're trying to install some package in it. Debian goes and looks for that package in whatever repositories it's configured to look at, except all of them. And if it finds that in more than one, then it's going to apply some logic for how it picks them. For example, it's going to look towards the highest version number that it sorts by. Okay. And if it finds multiple that are the same, I don't actually know what it does. I suspect that it picks one randomly. Or it's in some priority order that it's in the index that might configure. Maybe. I don't think they, yeah. I don't know. I mean, there's a lot to be, there's a lot of tree barriers, but they might have lags. So if you find something in one or not the other, that's likely you should probably use that. Yeah. It's the point has version of often people only use one mirror anyway. I think it's, yeah, it's coming. So maybe a scoping question is, how much do we want to potentially unravel? Like we basically said, we're going to start over with signatures in a registry. Are we willing to start over with how content is addressed in these various runtimes? I don't think they can change very much. I don't know. That's what I'm saying. So, but I think we can, I mean, we're going to tease out the separation of a registry and an artifact and make those two separate elements, which if you look at most production systems, they make the registry environment variable or some variable of some sort. And then everything to whatever portion of what they think is the right is also referenced separately. So it's not that existing work flows don't already do this. And we're going to make that change. That's a thing. Some do some don't. And the right side of it isn't necessarily like I could have 15 different people that are all having something named web. And they're all different. And they are not the same. And if you say that they're all the same, then you're going to run from it. No, I agree. That's why I was asking. Like the way we treat ACR, there's no hierarchy to it. We treat slash as just a special character. It's just eye candy that makes it look like, you know, it's a hierarchal main space. But we don't, we're never, well, never, never, so never. The idea is that something slash and is too below it, that configuring up here would allow different, you know, inherent permissions. So it's not that it says that special slash characters couldn't be added to things on the right side as well. And you have the left and the right. And as long as they move together and still work, you know, something that says that that couldn't be a solution that we generalize. So it allows you to have artifact names that can have some amount of hierarchy to them. But to me, again, visual is new. I think you're still conflating like the location with the name. I'm actually trying to come separate. Actually, it's what I'm trying to say is that there's a registry to the left and there's the artifact to the right. But that's not, that's his name. That's multiple things with the same parts of the right that are different. And people use these things in very different ways. Yeah. One of the things like. That's a box already. One of the things, one of the ways that I look at something as like a service owner is I don't really want to force a particular workflow on a customer. Right. If they have something that's working for them, I want to help them do that. So I don't want to force them to change the way that they're naming all of their images, just to fit into like, this is the only way that signing works. Well, I'll also, because we need people to actually use signing. And if you have to change your workflow to sign it, then it's difficult from the start. But I am suggesting that I'm not, I'm not suggesting that they do change. I'm suggesting that there's a way to to glue them together so they don't procedurally change. Well, some of your workflow has to change because you do have to define who you trust and you do have to define what name you trust. Yeah, I mean, but you have to, you can clearly obviously have a workflow to change because you have to change it. Yeah, you have to take a thing. To be fair, the workflow to change you is because people are asking for signatures and there's not a good viable solution. But yeah, so yes, the workflow is going to have to change. I guess so, I guess, I mean, well, unless we can come up with an ideal thing that just makes it work without any changes, which I think is unlikely. But I mean, the ideal would be, would be something, you know, would be something where you could configure something that gave you at least a minimum sort of guarantee without doing much, with as little change as possible. But really, the idea, I mean, we don't, we want to, I mean, for example, one of the things one of the things we were always intending to do and for reasons, and it was difficult doing that, it was just make all Docker clients always check signatures on the official images because that should be something we can configure without. Making any changes to anyone's workflow or whatever, at all. Because it's just like, more or less in control of the client and the registry in this case and we could make things work. I talked about the fact that there are 132 different signatures to project for that, is really some of which are used for multiple engines and other things. And I may be really empty and I don't, we've never actually done it, but that would be the kind of thing that in principle you could do without workflow changes. And I think that we want to have at least some benefit with the smallest possible workflow changes. If you want more benefits, you won't have to make more changes.  We're not ever going to get around that. But if we can give people something for very little or even something for nothing, that's even better. So to me, it's a question of degree. And maybe this is a really bad analogy, but I'm going to try it anyway. We have different vehicles that take different fuel sources, right? You've got gasoline cars, you've got diesel cars, you've got hybrids, you've got electric cars, but you drive them all pretty much the same way. And so even though there is something that's different about it, maybe you'd argue one might be better than the other, and I have to do something different with how I put fuel in or do I go and charge it. Like the main part of like, how do I drive it is the same. Right. And so that's kind of what I was getting towards is like, I think considering the need as an attribute in a signature, like there are other attributes we want to also consider, right? Like we want to look at 30 refers. We need to look at some of the like when was the thing actually signed. So the signature attributes in some way need to be defined in a policy and that policy needs to get validated without a change to the workflow of how containers are actually pulled and deployed, right? Over the minimal changes as possible. Now, if just for a name as an attribute we're looking to sort of like, see if there's some other way to address it, what about the other attributes we may want to validate, right? Like we're creating multiple different workflows for different activities that might possibly come in. I think these should all be part of like, here's the policy set of attributes. Whenever the signature is validated, you check against those attributes from whatever's in the signature and that workflow should state the same because if you think about the reverse case of like, why am I validating a name? I'm looking to see that this name hasn't changed. Well, if you're looking at the final name then and you have a valid signature or something else. So for example, if it's MySQL versus sort of like Outlook from Microsoft, from Microsoft, then you could just read them up what to MySQL and all of a sudden that would pass the name check, right? So I don't know that the name itself is a way to validate an assertion unless like you have all the other like restrictions in places. Big stamps, no host name. Those are both I've seen like where they're like, hey, if this was signed by, you know, within two, anything more than two days, for example, or five days ago, don't do it. That's not, that's a different thing but at the same time it's a validation process. By name, we can just assign a name. Right, sorry, which is sort of, I don't know, we were kind of being explicit about that, but I mean, you were kind of explicit about that. And, but I mean, no three B one times nine. So it's, and so I think that, yeah, by name we didn't mean an arbitrary name, we happened to find it on the process. It actually meant something that's validable but it isn't, I mean, it's on the registry point of view, it's like, you know, you push something to the registry with a particular tag, you expect to be able to validate at the end, at the end of when you're running it, but it's the same thing. It doesn't really matter what the name is, it's just you have a global unique identifier that specifically addresses that kind of bits. No, it's not a maybe, I'll let you just use the hash now, you wouldn't care about that. It's a human understandable identifier that people got used to, that they have to give things a name when they put them in the registry. That means something to them but doesn't mean anything to anyone else. This is why to me, like the set of attributes that you'd want to validate go into some sort of claim that ends up being signed. Yeah. And like as part of policy that you apply when you go and say, this is the image that I want to pull, these are the attributes that I want to validate. I'm trying to, so what I'm trying to forget, I'm not going to give this quagmire the, I feel like we're not going to, we're just spinning, which is good to kind of lull on some of these things, but part of what you mentioned a little bit was, I'm like, what do we validate? And I was trying to capture that, but I think there's a certain key set of elements that we definitely wanted to take, like who would be in the team that signed it? Like we need to know that it was Microsoft that signed it versus Microsoft that Justin over here has made it up. There's something about the name. Once we get beyond the name and the signing key, even in the version honestly, I get a little nervous because what is the version? Is it an opaque string or is it a, you know, it was called God of Convergence, I just put a blank. 10 bucks. So, right, 10 bucks. Right, right. No way, no, it ain't been a campy for a lot of reasons too, so that's why you didn't get caught up. So, and then there's like, hey, there's a whole bunch of things that policies managers want to use, and they should work with an S-bomb type of thing. I'm just going to say S-bomb type of thing, because I purposely did lower case O to be more generic and not buy into a specific S-bomb. And then what our scope is, we will make sure whatever S-bomb they put in it, they can attest that it is still the S-bomb that it was. That's what I was hoping to kind of carve off what I think we can, this team can accomplish. I feel like we're struggling with stuff. I think we just agree. I don't think we disagree, you know, but I think that there's a difference between the minimum guarantees you can get from the smallest amounts of work, versus I want to set up a detailed policy framework that lets me customize all sorts of things about examining an S-bomb and what I can do. It's also a fairly valid use case, but they're different use cases for different audiences, and we need to be able to support both of them. And you have to get something out of the simple use case that at least gives you some guarantees, because otherwise, we're not going to approach any kind of universality. And we've got to give a whole set of things you can build great tooling on to do great things that we hope people will build a community around, you know, providing more complicated work, though. I mean, I think that maybe having some sort of claims in there, we teach them that, because you can get to the point where you say, I'm going to validate the signature on this is what's produced with the key that I trust, but not go and say, I actually want to go look at these attributes, and then I don't really have to change my workflow. I'm just doing dr, pull, dr, run. But if I want to actually go and validate some of the attributes that I say, well, this is, you know, after I pull, I can go inspect and say, this is what I expected for the countable names. This is what I expected for the version number that was signed in there. And if it's not matching, then maybe that's not something I trust. Or if I find something in there, but it was signed by a different key than the one that I trust.  So, I think that's too little. Well, I'm just trying to capture it. What do we think is the minimum viable thing that we want to attest to, like without bringing in oba and s-bombs and all these other things, like you just get out of the box registry with whatever version and whatever we decide to call all the stuff that's done. Well, what do you get? Well, if you look at signing in general across, not just in container space, but in the sense of what you're really looking at is who signed it and when did they sign it, how long is the signature valid for, right? Outside of that, everything else is really customizable for different engines. And so, I think- I'm going to identify the thing. Sorry. Will you identify the signing entity? Yeah, the signing entity, not the content. So, those are the three things that you typically validate across everything. And so, I'm curious beyond that, why is the name or the version number, like why are those part of the simple validation use case? Yeah, I keep coming up to that. It's going to bother me because of what's the value of the signature, then, if you can just shoot the image digest. I mean, okay, let's go back and say, yeah, I wouldn't disagree that that has some bad value. So, if you say, for example, that will tell you, for example, that you are happy to install any software that Microsoft produces, however, hold or bad or good, or whether it's a SQL server or Windows, or mind-tweet that, I mean, so it gives you some like, but you know that it's from your friends at Microsoft. So, and you could- So, it doesn't give you anything other than that. Right. So, the question is that, is that, I mean like, yeah, I have to, do we want to, is that our base? Yeah, I guess the question is that the base that we should want is does it match our threat model? Can we produce something that fits with our threat model that will provide that and nothing about that? Is it? Starts with that. Whatever it is, I'm sure it can start. And then can we incrementally add features on top of that? Or all the projects can leverage the fact that things are signed? Such as? Well, I mean, I think that we would, we want to be able to demonstrate that it's a, again, that you can add features and get more guarantees on an incremental basis from that point of view. I mean, ultimately, I'd love for us to do- I guess the question is that, is that the minimum? Like, this is what I'm hoping we will be able to demonstrate. It's just we're delivering the blue things, right? So that doesn't tell you what you're guaranteeing through that process. So that doesn't answer the question. So it doesn't tell you, that doesn't answer the question, am I getting Windows on my Twitter on my Kinect's cluster? I mean, you know, the other diagram doesn't specify what the question you're asking is. Is your question, am I getting anything from Microsoft's great election software running on my Kinect? Yeah. Am I getting what I- So one of the things that we talked about was the balance of the trust and first use, which the first use might be a kind of really bad thing that has to be signed, versus I can excite them out of that. Personally, I think that first use was a, I think it was a huge mistake and naturally, they won, because I don't think that- Well, sorry, the trust and first use thing is really part of, it's with the thing that docket, something that comes in trust, which is naturally support other, any kind of thing you want. But I think trust and first use in a ground environment doesn't make any sense because everything's okay, but almost every use can be first used. And so- Yeah. So it's really, it's very different from the systems in which first use is good, like FSH, where you repeatedly make the same server, and hopefully you have a process for doing it since I know it's from your, say, from your laptop. No, right. And first use, you can have a first time thing and then you can do it for, you know, potentially months at a time. And it's kind of, that kind of model works well. But in fact, like everything that stands out to be a federal business, never use anything before. Everything's first used. So trust everything in this point. Well, but the piece I think I have a scenario some of the talks about it is, I could also, like my dev environment might be trust and first use, but my staging environment says, no, here's the, I have to pre-provision the things, the keys that I trust. And there's a flag that's set and some yet to start alarming it. I, I'm not sure. And like if you're going to do trust and first use, you might want to sign off. Thank you. Thank you. Thank you. I'll be honest on it. I know this redent think it gives you any security at all. Yeah. Why do you hold, what's the case to hold on to that? I thought that was slow hanging fruit to get away from. To get away from trust and first use? I was trying to avoid, so there's, there's a, it is signed versus not signed at all. And then it's, so it's not signed at all. I trust anything. I don't trust anything. I accept anything. Like, I accept everything. Then there's, I will only accept things that are signed because at least there's some traceability of what this thing was. It's like, and then there is for it. So yeah, that's a no data. Yeah. I have no, it's a good thing. I was okay. It's meaningless. Anyone can, anyone can sign. Everything can be signed. The original Doccatani model had all images signed. Yeah. Because it generates the random key for all Doccatani from this. And not everything. But you had no idea what the key was. Yeah. Okay. So the key was literally signed by entity. We have two models of doing that. Right. One is you get the key from a trusted source, which is like, you know, like, okay, I trust Microsoft. I'm going to get whatever public key Microsoft is giving me. The other would be that if you go down the PKI route or the search route, like you get, like you trust publicly, public search to kind of go validate whoever the organization is. But somehow you do need to configure your trust store. Because otherwise you go back to the the value of like, why are we trusting that to the first place? And that was why, that was the idea that there's some sandbox you can play but it gets tightened up along the way and as it is tightened up, you can ultimately trust or these are the things that I trust. Yeah, I think, yeah. Does that mean you trust, I think it's something that we do need to go make some of it? It's like, I think there are, I think there's a bunch of usability questions around that. For example, there are a lot that can kind of be like Microsoft is straightforward. They have places where you can reasonably get their public keys from versus there are like millions of users of containers who you don't really know where you can get their public keys from. And for example, we might want to support registries having a delegation mechanism where they sort of give people key for their time, for example, I mean, like for billions of users on I think there's a lot of places where I'm going to go to these more places like my hub or the Azure Marketplace or Amazon Marketplace and vendors are going to put content out there. And I want to be able to get that. I shouldn't have to, every time somebody wants to do something like company or my small startup, I shouldn't have to go pre-provision something. That's one of the ideas that trust and first use would actually be useful there is I can get stuff from the marketplace. I get the TDI trust, maybe as I'm trusting that marketplace as a location. I mean, you want to do that, you don't want to offer these, you actually want to have an easy way to put that in your Qt config which is which is a, you know, a nice validable integration that you can see what here was you trusted and continues to validate that later. And I deal with keyword data. It's definitely don't want that to be first use because you need to be able to audit but you got the key from them. Yeah. I was thinking the key for the identity that I at least have some traceability like the thing that I got on the machine I actually know it came from full entity. Now whether I trust full entity or not is a different question. But don't know that it came from full entity. Right. You know that full entity is fine. No. You know that you know that there is a signature that was created by that key and all of the information you know and whether or not you trust that key tells you like, well, I trust that this key is full entity but there's nothing about the key itself that tells you anything about the identity. Well, I can generate I can generate a key that does have that that does part of the needs that you have that I was thinking about. You can't because I can generate a key that says I am Microsoft and then if you install that then now you trust me to be Microsoft even though I'm not my first use. It's not about first use. It's about like what's in the trust store. Like this is a key that you are you have some mechanism to say I trust this key. Like you need a root configured somehow. Like either you're getting keys from every organization or you're getting a root from a public CA and that CA is fine. I was thinking along the whiteness blacklist kind of model was like you know until depending on the environment you know like there'll be a set of keys that there'll be a set of entities that eventually get you know it's covered with scanners. The scanners know if they see this thing like I'm not going to allow it. If I see a set of keys that I don't trust like some signatures that I don't trust for certain set of keys then I don't want to block those. But in some environments I'm going to allow most things unless they're explicitly blocked and they're blocked by probably the vulnerability scanners that I bring. I think I'll block those keys. I mean never because people can just invent it if they're going to get it. They're going to block it if they're going to get it. Well you're you're basically blocking known content and when they go off and span on spawn another one then they have to get that new thing out in distribution again. That's not really the value of it. Because you can just go down right here key. But you can just go down right here key. But are they pushing it into the ecosystem as fast as I can block them? Like there's got to be like I can I can start to keep getting it over again. No they would they don't pay too much. Quite a bit. All right. What is the base of which we want to stand on? I feel like we're on this big quicksand pond. I think there's a is there is there not just a fundamental question. It sounds like trust store is a good replacement. But I need and so there is again so the degree of do we have much operational change we're going to take configuring trust trust store seems like a really reasonable I mean you have to do something to make it better. Again trust on first use sounds pretty terrible in the crime space. So I think that's a that's the question. It's interesting. It's not going to become one of the trust stores that I can reference that things that get as you call them today certified actually go through something that says OK to get into this this trust store then you have to be an identifier person. You have to give the equivalent of your passport. So we know or customers could have the ability to do that. We can figure that out. I think the answer is that you're always relying on that. Now registers do not want to become CAs. No. Yeah. I think that's I think there's like even all the big most people in the room. Do you want to become a CAs? The registry I mean you I think I would have a customer to you want to come to CAs for their entity but I wouldn't want to and MCR might have to be the CAs for its Microsoft software. Now we're big. And so there are places where people will want to be CAs. So if there I think part of it also does point to like the PKI I just especially want to have this kind of like links in the part of that. But if for example Docker might be a CAs and say like we're going to validate. If you're if you're asserting anything from for your repository and beyond like here's a repository container you can get from. You're trying to say like we've scanned all these containers or we've established trust for all these publishers right. Then potentially but the CAs role is really more to validate whoever's coming in and that could be a public CAs. There's no reason to coming in or the content that's coming in. The who not the content the who is signing right. Okay. And you have some kind of validation there because signing is an assertion of liability in a way right. So if I get that constant issue and it's signed by Microsoft then I know to go say hey this gets signed by you right. And so you have some like the way code signing certificates that are issued you have either organizational validation or center validation which RMS and there are sort of like there is work going on in the code signing forum to kind of see how to kind of go to address that. But this goes back to like what do we want to identify. If you're trying to identify organizations which is one use case you do have to go down the route of OVP to SCA. But if you're also looking at saying sort of like I want to trust this user that has published to this repository. Then for that that repository will need some way of setting up a CAs that allows that. Well all repositories when I do that probably not but some may right. And I think that's and if you look at all this internal use case as well. So for example if I them on the signs that I want all my developers that are sort of like publishing containers into my internal repositories to sign them I'll probably have an internal CA that's then issued each individual one. So or multiple of them. So yes. Especially gets largely multinational different organizations or MNAs even specific verticals that have to come back and forth. They need to be able to have like trust mother entity. That's maybe a private CA as well. Right. So we may have private CA's public CA's. I don't think we want to tie them with repositories but we'll need to think through what are the scenarios of what identities we want to establish to really go back and see what the CA's would look like. Yeah and then there's also I think the question of with that scenario is when and how do you actually want to validate this? Is this something that you at the point at which you're about to deploy into cube? Do you want to do the validation of is this Blackface terrifying department B or did you want to actually do that earlier in the process and just sign us something validated there and that gives the again of a you know cumulative just as a I trust I trust the stuff that has that comes from fraud and signature and fraud doesn't it's a isn't perhaps I've meant to define it like it's just a key that I use but in that case you can probably because it's been through this process kind of then so it's going to with the question of where where do we want this at which of these checks are essential to do when and does it or which ones do we want to move around and do we want do we want to require availability to do things in first places or not and do we what and what do the simple workplace look like and do we feel do we support where do we support what you know where do we want where how much choice we'll give you about where they can do post policy for example you can tell that I mean your reaction so then it's you've got to provide three plus marks like you you can't account for every you know small enterprise small customer case versus very large case where they're they are managing their own say they're remotely manageable and it's got to be yeah going up to support those yeah and I think that's why this whole that statement that I thought he was about that I kind of land on was if you you have to be able to have some control of your own destiny as an enterprise I'm going to be able to with it with an assertion and arguably a change I know better and so I'll accept some things as trustable that there's a security organization there that's going to say I trust these keys and therefore and for these reasons and and that seems to be missing and I mean I get you know these are the things we have to recapture in the requirements exactly what these these kind of the things that we do not want to constrain and things that we absolutely absolutely and maybe it's or just the debate is does it need to be that but I mean one there's clearly the case of it's complicated for us but how flexible does it need to be is I think where you were you were just trying to go the other question was like we say that complex players need to be encapsulated in a simpler play for example for example is making a complex decision and then just putting a signature saying that policy was that complicated that as policies and processes was part that's encapsulated in a simpler play for that matches the simple play or what do we need to support all the complexity in any potentially in any location for example that's the kind of question about where we like not about what we need to provide but where we need to provide it yeah that's what I mean we need to do that no no you don't need it we need to talk about where what what are the different places that it could happen that's not apparent to me so it's out with the the I mean there's there's I mean there's generally a workflow from where things happen between the build and prod that it may be involved any set of steps I mean a lot of people do a lot of people want and the one of the things that we're actually very noticeable about military we want is that even though this is not what it's the guarantee that provided people wanted to use signatures work in this workflow steps to say or they or they thought that that's how what the model would be military who implemented did so they wanted to be able to say I want my legal development like I want security designers off the face gets going as far as I want and there's some sign-off saying it's run through CI now so these are kind of and therefore you could also have that to say and I wanted to come from one of our validated suppliers who are listed in this 468 page document to reach those which might as well product for an LPU because they come under the you know this part purchase list and we definitely don't want these oracle products because we're not paying them any more money and so those sort of it is the kind of processes that people want to implement that how you implement that it is whether you do that I mean there's lots of ways you can implement those with signature I hear a couple of there's like a hierarchy of how big you are kind of thing right there's the Microsofts and oracles and new utilities kind of thing like they want to make sure that they can have some kind of certification so this is the software that we produce and it should be traced all the way through then there's the smaller vendors that like hey I'm not going to stand up whatever that monstrous infrastructure is but because I make my stuff available on the AWS marketplace or the Docker hub or something like they provide some signature solution that says hey this is that vendor and they help to make sure it's somewhat stamped with you know