 Hey, Mark, how are you doing doing good? I just updated the full request with some Some of the scenarios a little bit more flashed out I'm just gonna post that here I didn't get a chance to get this published before the meeting so I'll give you a chance to read Yep, so I was reading through the document And I have one question So in our use case With with the current notary v1 We are also looking at Something like a self-service portal or something like that where teams can create their repositories and the and the keys belonging to those as well authorizing or Or the authorizing delegations At the first side, I don't see this back in in these key management scenarios Would it be something we we need to add to notary v2 as well? So let me understand that use case better. Is that essentially saying that if an Administrator has created a root key Uh, they can give permissions to others through some portal to get delegate keys from that root Um, yeah, so You have seen the demo last week, right? Right So so currently, uh, we we connect this uh, this solution to to one notary server Um, and in there someone can just create some some target keys and Add delegations for for that given target Um, but now with with another organization, we we don't have one registry, but we have many registries As well working with docker hub And so so we need to manage keys for all these different solutions. So Our id with notary v1 was If we want to manage that till till the time notary v2 arrives We need some self-managed portal or let's say your team is going to publish X number of new docker images So let's say I want to release docker image a b and c Um, then I would create uh in this portal the, uh, Repositories And then based on our iam system. Um, we give people access to Manage these repositories Then they can Themself Add delegation keys remove delegation keys, etc from those repositories Right, I think one of the things that we were trying to do with notary v2 Was split the registry from the Signing component, right? And so rather than going having like a notary per registry um, I think the approach here turns into you have like a single service that's telling you essentially Which public keys to trust and which like delegates have been revoked And and that shares that information But you can essentially publish to any registry With one set of keys if you wanted to And then on this on the flip side anyone that's actually pulling containers They can also define Registry independent keys. So like they'll say here's the keys that I trust And regardless of whichever registry you're pulling containers from You can validate against that. I think this enables us to do things like Migrate containers from one registry to another um, I think you know as I've been flushing out some of these use cases What it's kind of making it more clear for me is What does the rather than a key management service? What's almost like a key sharing service look like in terms of how am I sharing my public keys with others? um, and I think that's kind of like a component that Notary like the notary server aspect of it is almost turning into Where rather than hosting signatures, it's hosting for like, you know Here's my developer identity here are my public keys and here's the keys I've revoked so far Okay So so okay then then we have Let's say one one notary server to manage the keys for different registries But what if we have a big organization? Where there are many many docker repositories Independent on which registry this is How how can we ensure that A team can self manage their delegations I think that's one where we want to define more on what the functionality of the key management service turns out to be right like I think here There's a few different options and creating delegate keys I think this comes this is something we'll need to flush out more in terms of how are those delegate keys created, right? Right now. I think what I have spelled out here is just the steps that need to get taken I think there's a very good call out that you're saying in terms of like, you know, if we want this to be a centralized service How would that operate and I think that's one where The key store kind of Matters in the sense that If the delegate keys are being stored on local machines in terms of like the hybrid scenario Then really it's a matter of wherever the root public keys are being stored that you can get the The you haven't you have access to kind of go get those signed to get whatever you need signed for delegate key to be changed to the root key So I can add I think some steps in there that calls out. I think this would be line 38. Sorry line 39 the publisher creates new delegate keys and local machine that change your root key I think that one can get flushed out more in terms of what the The design there would look like where if you can specify where these root keys are stored Based on some identity access management, you can go get your delegate keys signed by the root key So as I was thinking in our situation we we have clients where There is a requirement that for example they they cannot connect to the internet So with with this solution that means there is one Not to reserve or somewhere in the cloud So what about if if this client Needs to run a not to reserve or in their internal network, but they still need to be able to pool Images from from docker hub for example So I think the the key management aspect of it may not necessarily be done for notary I think the key man isn't sort of like what what's traditionally been considered the notary server, right? Uh, the key management would be something that's more of like A publisher only solution right because it's and by publisher I mean everyone that's involved in sort of like building and getting a container into a registry, right? Yes Notary would be something that you need for communication between the publisher And the employer So here I think this goes more into the Key management and I think This is one where If you look at key management, there's going to be different ways of doing it Some people may do it through like a local key store Some people may do it like as you are in terms of like, you know Where you're protecting your roots and then you're authorizing others to get sort of like Delegate keys And there you may have multiple roots that you're creating and giving like, you know roots across different teams or different organizations, right? So I think the hybrid scenario flushing that out and how those keys are delegated will address the Delegate key generation But the notary essentially becomes the more of the like you have a root key How is that root key available to people that are deploying to know that this is a root key for this publisher? And I think there we'll want to list out what those scenarios are, right? Because there's going to be cases where that's a That's a private notary server being used within an organization It could be a public notary server where, you know, you are sharing Sort of like anyone that's you know, publishing containers publicly There can be notary servers that Potentially are hosted in air gap regions, right? So I think the this is one where I want to go back to the larger group and and kind of go with this proposal of What the notary server is changing into? Because the notary server today is hosting all these signatures, which I don't think is needed it really needs to become more of a root key store and a revocation List store, right? And then I think the the point you're bringing in is the delegate key generation, which I think goes into the hybrid scenario And that's one of the things I think we want to flush out Because I have I actually I'd also like to get your thoughts and sort of like, you know When we do for example the local key store, right? Are we are we saying that like, you know, we're going to allow root keys to be stored in plain text Or do we want to actually kind of specify a key store? Because then that key store can become part of how the key management is done, right? We can specify and say that if you store your root key this way Put some access control in front of it and then all of a sudden you have a system that you can use for Delegating keys from there So, um, yeah, what what I was thinking is if if Um, so so I'm just talking about a web interface makes it more tensible, especially for users or people who need to use this in a bigger Organization who are not that deep into the topic So let's say We have a web application which integrates with the the enterprise single sign-on system Based on that, uh, this web application we can Define some role-based access control on on different features And there people can just define okay for this repository A B and C Is allowed to publish images So that could be CI jobs, but also in developer individual developers Um, and similarly we should also be able to remove those keys and um Yeah, to prevent that anyone randomly creates those repository keys We could for example, uh limit that to some kind of admin user who who takes care of that part So that allows us to use some self service portal Yeah, I call that out in the key workplace and in revocation use cases With that, I think what I need to kind of add in now is uh elaborate publisher to not just publisher But in some cases you have an admin user and you have a delegate user, right? Um, yeah, so the the admin user is more or less someone who is able to create target keys Maybe root keys depending on what the strategy is currently we we just use a single root key for registry So for a internal registry, we deploy this web application that we have as we we didn't made it In in search way yet that we can support multiple registries With notary v2 that probably isn't required because the the keys will be reusable across registries So that's that's from the publisher side, but what i'm still not entirely Or what's still not entirely clear to me is what what happens Let's say I I now register which keys and which delegations are are in place Um, that's registered against this single notary server Because whenever I create those keys, uh, we also communicate with another server. So it's known to the notary server But what what if I now have this internal server? Um, or this internal notary server How how do we sync up different notary servers? Maybe AI gapped So people can still use it. So so let's say in our development environment We pretty often need Access to docker hub because some of our images depend on images from docker hub But in the runtime environment where we run our products Um, we might just want to only run against this private registry where we have published our own images So we can keep that in a closed network environment So the right I think the The the part about like the delegate key chaining to the root That information should be part of the signature, right? Um, so you don't know Yeah, so so the solution there is more or less like how it works with with tls certificates for for securing your your htps traffic Is it that we we are going to treat these root certificates And maybe an additional layer of root certificates just like you have certificate authorities intermediate certificates, etc Um, and that we install those Certificates like the root certificates intermediates we install that on the system And then by definition everything created underneath that Structure is trusted Right, um, and I think I put in like a uh, let's see Uh, whether we wanted to do this where we wanted the intermediates, uh, that's an open question that I had um for line 62, uh, in terms of like, you know Do we envision having this would be would be useful? Because the question here comes in like, you know, what's the guidance that we give like, you know, just create a new root or create a subordinate I think, uh, subordinate like from large organization perspective makes a lot of sense Because then you have different levels of control, right? And so I kept an open item because uh, I I didn't I wanted to get some additional feedback on that But yes, you're absolutely right. I think that's the I think that The signature validation independent of registry You can do this in air gap regions. It becomes a question of how often you're syncing it How often you're getting sort of like the revocation list? It moves more towards more of the tls format. And I think this also creates the potential of so trusting like public certificate authorities where You know, if you want to use, uh, sort of like a Public cert issuance, you could potentially go leverage one of those to also kind of get certificates and use that as a spending mechanism as well. Yeah, exactly because Uh, in in our research department, I have also been looking at for example, uh, let's say, um, if you want to use modern technologies like hdp Server push or g or pc kind of services you you need to run them on tls Um But the problem or the difficulty with many of the development teams is they they don't know how to get certificates or you have to struggle with these um, self-signed certificates, which are not trusted everywhere So I was also looking at how we could utilize hashicorp vault where we could set up a root certificate or basically import our company root certificate in hashicorp vault then Depending on our strategy, we could create development intermediates qa intermediates and production intermediates and Based on those you can define policies in hashicorp vault And with a policy you can say, okay someone who Retrieves a token with this policy is allowed to create certificates or refresh certificates or whatever and based on that you basically Allow people to self manage their certificates So you could say, okay developers are allowed to issue new certificates for for development So for ci but also for local development on their own laptop Um, and those certificates because they are signed by the intermediate and the the upper root certificate are automatically trusted in your browser So those kind of certificates they can self manage but production certificates That's just a small set of uh company administrators who who can create those kind of certificates So we were thinking about making this more or less self-managed So then I also looked into Let's encrypt and the act made protocol Like how you can automate retrieval of those certificates and renewal and and those kind of things So now we we are talking about moving more or less into this tls certificate kind of approach I was thinking Wouldn't it be smart if we would integrate with this act may protocol Where you can also benefit from from automation and standardized apis which which are already there Done by let's encrypt and and and others So there are um some concerns with acme and um I think that's one we can discuss further I think that's actually worth the conversation in terms of what are the kind of automations we'd want to put in place Uh, and there could potentially be things in terms of like, you know Uh, whichever domain you trust things like that Then there's a few different approach to that like you could do it through automation from for example Like if you were trusting domains, you can do that through domain validation Um, you can do that through email validation as well if you wanted to do sort of like email validated certs Uh, there's a few different mechanisms to do that. Um, but I think yes, you're absolutely right like exploring The different automation options and seeing if any one of those would make sense. I think that's something you can So what I look in so what I do personally to get my certificates for example is uh, I own my personal domain So I use the DNS challenge So that allows me to just create all the certificates for my local host Um, um, I just update my host file put for example my dns name in there and I just request certificates for my local host So that's based on the dns challenge but now let's let's Take this scenario where you have a ci job which takes care of signing your images And the ci job needs to get uh, his own signing key So then it might make sense to to securely Provide a a signing key. Maybe that delegation key is just valid for for 10 minutes For the for the lifetime of the ci job where it can self register this Uh certificate, um, maybe based on some new Acme challenge We could validate us that this ci job is allowed to do that And then after this this ci job finishes then this certificate kind of expires mathematically Meaning you can never leave certificates Flying around on ci servers and stuff like that, which is of course also a security risk Right um, I think they're the uh, one other components, uh, that does come in, um, through some things like that is you'd also need to um, get a timestamp signature on that, um And so uh, that timestamp signature would need to get created, uh outside of the, uh, of the Uh, the build pipeline right out of the outside of the ci system for the, uh, certificate time to be trusted So I think that's That kind of automation could make sense I think that's one where Let's add those two ideas to like, so I think the first one is the Automation and then getting certs from sort of like a public c a Uh, and then the second one that we were looking at Uh, would be making sort of like, you know, short list certs, uh, that Make sense for sort of like the ci Uh, uh, ci cd pipelines, right? Uh, and then the short list certs I think they add in sort of like an external timestamp requirement to make sure that you trust the Uh, the the validity period like signature was generated during the validity period I think those are both things that we can, uh, have a wider discussion on for the automation For the next meeting that we have I'll I'll I'll come up with the short presentation on the The different mechanisms we have for that So I know that we can do sort of like domain based challenges. We can also do sort of like c name configurations I think the the one thing that comes in here though is now To publish a container You also need to now only domain, right? And so whether we want to go down the route of domains or emails I think there's a few different options we can explore Um, I I want I'll I'll bring into like a more exhaustive list and we can run through those automation options and see which ones make sense Yeah, no I think for for the rest I think the list is Pretty complete, which you you are showing in this PR Mm-hmm. Um, yeah, so the the thing we are mainly concerned about is How do we manage those keys? How do we also revoke people when when they are leaving the company or switching departments? So from the aspect we were looking at it Yeah, what we we currently do is just deploy the solution many times for every registry We have we might invest some time on this web application. So you can actually have have one deployment of this to to manage many notary servers Mm-hmm So the the the only thing which Yeah, we need to check in notary v2 is then How the desynchronization of of these things would happen if there are many notary servers? So I think what I'll do today is add in what The notary server like what role it is serving here and kind of what the key management component is serving for Within the publishing environment, right? Key management should should just be a client on top of the notary server to To create those certificates So currently notary or docker trust they they store that in this local folder That's also what we did with this web application. So this web application has its own local folder where the keys are stored currently And depending on on time I I can get for that I I could also do a small poc to store the keys in In hashicob vault, for example Um, yeah, and for that you already have a lot of items in this list like defining an interface. So so cloud providers can can implement their own Storage Yeah, I think that is that's already covered. Um, yeah, and the other thing we are currently investigating is Uh, what if a developer loses his delegation key? He was the last guy who signed the image How do we do the rotation and replace that key? So so we can still continue to release images Okay, um, I think those are all great suggestions. Um, I'm gonna get those in by noon and share it um In the slack channel, uh, and then we can take uh, uh, a quick sort of like review, uh with the larger audience on monday And see where everyone's at. Um, do you I think you the the monday meeting time usually falls out in regular hours for you, right? Um, I guess so let me check the calendar. Do you know the time for that meeting? Um, yeah Yeah, that's seven p.m. So it depends, uh If my wife has to work she she works with shifts So I have to take care most of these times. Uh, I need to take care of my kid Which is kind of her bad time. Uh, it's kind of the time she needs to go to bed So then I'm always busy taking her to bed and So in incidentally, I can join Probably but I cannot not always tell that up front Okay, um, I'll go ahead and sort of like if there's any takeaways from that We can summarize that and kind of discuss that on the friday meeting again, uh, in terms of next steps, but Thanks for the feedback. I think those are all sort of like, uh, solid suggestions And so I'll work on incorporating this So, uh, do we also need to update a hackamd meeting notes? Uh, yeah, go ahead and update those meeting notes. Um Now I never used hackamd. So I only read the meeting notes, but let me see how this works I think we can also work together in those meeting notes, right? Yeah, so There's a pen icon, I think on the left side. Let me actually copy in the meeting template By the way, I just joined. I'm sorry for being late. We had a tap tough like standardization meeting that Took the full amount of time and then some it sounds like you guys might be wrapping up. Was that correct? Um, well the meeting was scheduled for a full hour. Uh, I think, uh Uh Marco usually needs to hop off But I think Trishank was supposed to join late as well. So, um, I can actually stay on for the full hour and Go through the so what I'm essentially doing is right now is I put out a pull request So I was getting feedback on that If you want to read through the pull request, uh, we can go through it And I'll make some revisions and for the audience on monday Great. Okay. Um, Trishank had mentioned he was planning to join this call. So I expect I'll we'll see him in a minute or two But yeah, that would be great. Um, where's the uh Is this posted in the notary b2 channel or where's the document that we're looking at? I just put it in the description again. Uh, It's the in the game Okay I got it. Okay Yeah, I think zoom doesn't show me chat history before I logged in unfortunately um, so it's only us do we, um, Did you take notes on the feedback and feedback I gave or Yeah, I was taking it down on pen and paper because that was easier for me. Uh, I'm gonna just add it to the hack and venus cool, cool So I I have to leave in a couple of minutes. Um, So I'll stay around for a couple of minutes. So I have to leave Okay, yeah, I have a couple I have a few things I'm just sort of noticing as I'm reading through that are Just like basic questions Is this is it okay for me to just start like asking things now or Let me let me think Trishank again because once you and he said he was joining Sure, um, I think whatever it's easy It's like if you want to read for the whole one and then we can go through questions or Uh, uh, whatever it's easier. It's like I initially had planned on sharing this doc before the meeting Which I didn't get unfortunately I get a chance to so, um, um either works for me I guess like one of the big questions I have relates to You you talk about like publisher shares the key and To me that's like a big There's like a big question about how that sharing happens and who it's shared with and why Someone trusts that they're getting the right public key I'm just wondering if you can like Can you talk a little more about that or am I thinking about this the right way or the wrong way or You see what I mean Yeah, I I completely get that question and I think that's one of the conversations. I want to have with the group Is identifying What that sharing mechanism is right? Because what we're essentially trying to get to is how does a publisher identify themselves to a Deployer Without really having to rely on a registry, right? I think that's one of the key goals of Getting signing enabled through notary v2 And so one of the options there is that the existing notary service that we have today Where you're sharing signatures That gets more turned into one where you are sharing key material And this would this could give you two options one where you're relying on a third party shared key material store Or you are setting up your own key material store And I think there are different options there that we need to talk through in terms of implications But at a very high level essentially what this is saying is that In the signing environment, these are the tasks that we need to take care of and in the deployment environment here the tasks We need to take care of And then the part that we need to still flush out a little bit more Is what does that key sharing mechanism look like? That answer the question It does in part It's great because it's one of those answers that that once me makes me want to ask like four other questions So it's like it was perfect The I guess like You talked before about Like the the previous model using something where The Like basically you said it was signatures rather than keys In in the previous top model. Can you just tell me a little about what you mean there? So with notary v1, right? You are when you're querying the notary server You are getting a As I understand the implementation You are getting all the different sort of Signature files, right? Or the the target json the root json the timestamp json, right? So those are all analogous to certificates and signatures I think the shift that would make a little bit more sense is if you move more into the model of trusted routes and trusted intermediates And have the individual signatures or the images Be transported with the containers themselves, right? And so that's kind of like what I was envisioning would make the The container image sharing much more easier in the sense that The the the signature for the container itself would move with the container But then the the trust sort of like routes and intermediates and revocation lists would Live more in sort of like the centralized service, if you will So maybe maybe the summarize is it's more relying on on the standards like tls certificates where you have root certificates, intermediates, server certificates, client certificates, revocation lists and and those kind of things Is that correct understanding? Yeah, it would be something analogous to that. Yeah yeah okay, um yeah, there's There tend to be a lot of operational problems with that model with Respect to like there's a reason why We didn't go that route with with tough Um, but I want to Like tree shank is now joined And I wanted to have a Like a a little more of an understanding like what the advantage is of of what you like Of the way in which you're describing things because if you link, um If you like embed signatures in some way in Um more directly in the oci metadata um then this Has a whole bunch of potential downsides In that you can't really have multiple people sign the same thing and um The signatures are also separated um from many contexts about The party doing the signing And so you always have to have some way to link that back to the Um Like to understand why you should trust this party And how you should trust them the kind of I think the the problem you're trying to solve with um With like sharing the keys and um Uh like a lot of the issues related to Revocation Um I I think um are a lot harder to do in in the sort of um tls model because it wasn't really built With revocation as a first class primitive It wasn't really built with like, um I I feel like i'm not i'm not explaining this in a convincing way like I I almost feel like I need a like a whiteboard and for us to talk through some examples Of the issue here, um Let me back up. Let me back up a moment and um tree shank. Are you on the call? Yep Okay, um May since this is my first time joining this group and I'm aware like I feel very much like I'm stepping into um Like you guys's backyard and talking trash and I don't I'm not trying to do that Um, I just want to I really am just trying to understand what's going on here. Maybe since you've been more engaged you can you can um Discuss and talk about what uh the key management scenarios document and stuff in a better way than I can Yeah, sure. Um, unfortunately, I just walked into the meeting myself. This is actually my first time joining and so I'm I'm also missing some context as you are Um, I do agree with your point about mapping signatures to roles rather than uh files themselves Because you're missing context about who did what that's the first thing I do agree The second thing is again, I don't want to talk without missing by missing Having missed a lot of context, but when I hear things like revocation lists, I get Slightly worried because that hasn't worked out well in tls as we've all seen nobody actually checks for Revocation because it's very expensive the way it's commonly done. So nobody really effectively does it So if we can do better, that would be great. That's all I I agree with that feedback and I think in terms of setting context. This is really the first time We're looking at this more detailed doc. Um, and so Uh, please like, you know go through it and all of this feedback is welcome I think the goal here really is to kind of come up with something that works At scale, obviously, and revocation is obviously one of the tricky parts when you go into sort of like a sort of Like trusted root configured model, right? Rather than sort of like having the entire sort of like signature map available So I think there's trade-offs on either side I think the question here is really highlighting these trade-offs and identifying What makes sense? So I think any of the feedback here is absolutely welcome The way they approached that I was kind of thinking of this more was triggered less around sort of like, you know, yes The roles do matter. I think here the roles are classified more in terms of the The roots and the intermediates That is telling you who actually signed The artifact in terms of like, you know, whether you are trusting a company in which case you might trust a root If you're trusting sort of like individual developers, those could be individual intermediates We can go up and down the tree and sort of like, you know, make this As complicated or as simple as sort of like, you know, the use cases require The part about sort of like the signature kind of being available with the artifact Makes the validation somewhat easier in the sense that, you know, if you have a Trust root configuration That's worked for a lot of other code signing use cases as well, right? And I think the question here is in terms of comparison What do we gain by either model? And what are the changes? I think part of Where we want to take this is One the core requirements that come in is that the notary server Needs to be independent of registries. So you could use the same notary across multiple registries And the other part of it. I think that's a core requirement Is, you know, the the aspect of like, you know, notary Servers potentially being private and public and being accessible I think outside of that how the pki set up how the signatures are set up I think is something that's open for discussion. So This is kind of like, I think like a starting point. So I'd like to get sort of like pushback in terms of like what we see as the concerns here And how those are potentially addressed in something in more potentially like even a hybrid solution if you will but If we start from there, I think What are the concerns here? And let's see if we can't figure out how to address them. Is that sound fair? Yeah, that that is that is wonderful. Thank you In fact, some of some of your use cases you talked about such as trust routes choosing on the level of the whole registry or Particular developers or the company level are interesting. These are actually some questions that we have explored recently ourselves We just got off on a call about one of these features and and it's a fair question about what we gain by Not by associating signatures directly with files instead of different different different roles, right? This is sort of in direction. It's a good question I mean, we certainly should weigh the pros and cons and talk about which one which one is the best thing going forward Yes, so Nias in the meantime, I uh, I wrote down Some of the feedback I gave you in the in the meeting notes With with some of the open questions. I'm not entirely sure if I I captured everything we discussed in the first half of this meeting Um, I think that captures it all I'll compare it against the notes I took and if there's anything else I'll add them in afterwards So I'll have to drop off now, but um, yeah, just give me post it. Uh, I'll I'll just check slack on the daily basis and If anything is required for my side, so just let me know Sounds good. Thank you cool Thanks guys Bye So Nias, sorry, I also missed some context about so where is it best to collaborate on this document? Is it on the github repository? Uh, yes, uh, if you can provide comments there, we can go through that That would we also have a record of like, you know, what the feedback we got and make sure that those are being addressed as we go through Got Thanks Yeah, I apologize. I didn't have enough I didn't get to stop then early enough where I could share it earlier in this black channel I'm gonna try and get revisions out on Wednesdays going forward Oh, no worries. I mean, I apologize. I didn't go through it myself So so one thing I'm I'm also kind of trying to wrap my head around here And I'm sorry if I'm like this might seem like a small point, but maybe it's important Maybe it's not um but Uh, one thing I really like you say is in parentheses a lot of times you say what you're trying to achieve by doing this action Like uh, publisher shares the root public key so other users can verify the containers before running them um but really, um You know, your goal is the thing in parentheses and the the You know, like I'm not I'm not saying I can imagine a scenario where they don't have to have the key But if somehow there were a scenario where they didn't have to have the public key to achieve that Then you wouldn't need to share the public key for instance Um, just like um If you for some reason had no delegated keys at all In the system. I don't know why you would anyone would think that was a good idea, but let's say you didn't do that um Then you wouldn't need the publisher creates new delegate keys on local machine that change a root key step But I imagine what you're trying to achieve with that is you're trying to make it so that um You know like Someone has the Ability to be able to sign for parts of things and you also have the ability to use multiple keys That like for instance different developers can have their own key Is that is that right or Do you see what I mean because like um, some of these I can understand directly the The reason for this and some of these I Guess and I might guess correctly, but I'm not sure I'm guessing right No, that's actually a good call out. Um, I think um part of this was something that I did want to talk about in this group um Should we actually prevent signing? of container images with the root keys because The root key is essentially Translating into a root identity, right? And if the root key is readily available then Potentially it is something that could be easily compromised There are sort of like implications around sort of like, you know Like you're having to more frequently update roots or more frequently kind of like rotate your roots and get that information out um So one of the things that I was kind of thinking about here was that, you know, if we come up with the key architecture where uh, the root key Is not something you can use to sign images with And you potentially have to use a delegate key for signing Does that help us improve the security posture of how Even developers like, you know, doing an initial setup like how their keys are managed One of the things we could potentially Leverage here is we could add in a key store requirement Where right now I believe uh in notary the keys are kept in a folder Rather than that could be potentially used like a java key store or some other key store where You're at least adding some level of protection where they're not like readily available And if the root key isn't being frequently used then really, you know It's really the delegate key that if you potentially get compromised in which case you case you could just, you know Rotate that create a new delegate key And use that and so that's kind of like where Where I was thinking about that where we would now actually require everyone to kind of use a delegate key for signing Yeah, that that makes a lot of sense. Um, and also how you do that rotation securely and things is also really tricky to do Right It's something like We've seen a lot of Big organizations were basically just push an update sign with the old key to try to rotate the key out When it's compromised and the problem is that the attacker already has the old key too. So You know, that's not not great. Um to put it mildly Yeah, I think there's There's a bunch of stuff in here where I think if I I wonder If at times if you could just explain like The outcome to like what like the purpose of doing the thing Rather than like the client the publisher will do x but why why they want to do something like this because, um I think it's It's easier than for us to go and see Like like the immediate thing I'm trying to do here is to try to reason about Like, you know a hypothetical design that would do this that used um Like metadata on the oci images and use something like TLS to try to do key management versus I'm doing something like tough And I'm trying to figure out like where the gaps are in the solutions and um, it's It's kind of hard to do that in places because Some of this is written. I think with them with a design in mind Rather than the outcome I think that's actually a fair call out. Um, I think I can actually elaborate on why these different steps are being taken and what they're accomplishing um and Like frankly, like, you know, if there's a better story for Getting the verification information out in terms of like, you know, if we're able to lock down roots and um, there's some sort of like signed metadata that's going out Like, you know, the same way that the tough sort of like framework currently works I think there's potentially a hybrid there and I think uh, you've actually called out one of the Concerns that we had with notary b1 Where to get a root rotation You had to sign with the old root, right? And so if that root was compromised, I agree with you there That's not the best solution And so I think really kind of teasing it apart like what does a root revocation look like versus what does a delegate revocation look like? I think if we can build in sort of like automation Where you're not necessarily having to go to a crl to kind of do that like that's great And so I think I will what I'll do is the next step here Is add in some of the motivations and I think you're absolutely right like that will make that conversation much easier What I'm going to do is uh, we only have like a few minutes left Are I'm going to take in sort of like the suggestions I've gotten here And and and make some changes to the full request and push it out today And then um, I'm going to ask uh, Steve for like 30 minutes on the monday meeting to kind of go through additional comments and stuff And I think that'll be a more fruitful Awesome, okay Yeah, was there any other comments that come up? Uh, and and that I could potentially address I don't know. Let me take a look at it and I might add comments to the br if you don't mind Sure Yeah, I feel like I kind of need that level of clarification before I can thrash and kind of add comments, but I don't want to do that. I'd rather Have like a few very comments Yeah, I'm gonna put in the slack channel once I have the comments added in so feel free to take a look at the request after those Right Okay, wonderful. Wonderful. Thank you. Thank you, Nias for for organizing this. It's a very badly needed meeting Yeah, we're sorry that we were late. We will um You know, we'll try to arrange things in the future so that we don't overlap with this and we can make this meeting Uh, yeah, no worries. I think I had to change the meeting in by time as well Um, I think said like uh, mark has been pretty interested in the key management side of things as well So I think 7 30 to 8 30 pacific time seems to work for people that are most interested in this side of the topic So, uh, we'll keep this hour going. Uh, but thanks for coming in and giving the feedback. I think all of it's very useful Thank you for being so gracious about it as well. Um, awesome. All right, well, we'll see you in the next meeting. Hopefully All right, sounds good. Have a good weekend See you all you too. All right