Cloud Native Computing Foundation Notary Project, 17 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF Notary v2 Key Management 2020-07-17

Description

CNCF Notary v2 Key Management 2020-07-17

A

Hey marco, how are you.

B

Doing hey hello, doing good.

A

uh I just updated the pull request uh uh with some uh some of the scenarios a little bit more fleshed out. I'm just gonna post that here in the chat.

A

I didn't get a chance to get this published before the meeting um so I'll. Give you a chance to read yep.

B

So um I I was reading through the document.

B

And I have one question um so so in our use case uh 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 our repositories and the uh and the keys belonging to those as well authorizing or deauthorizing delegations. um At first sight. I don't see this back in in these key management scenarios.

B

Would it be something we we need to add to notary v2 as well.

A

um So let me understand that use case better. Is that essentially saying that if an administrator has created a root key, they can give permissions to others through some portal to get delegate keys from that route.

B

um Yeah, so you have seen the demo last week right right, um so so currently uh we we connect this uh this solution to to one notary server um and in there someone can just create uh some some target keys and add delegations for for that given target.

B

um But now within our organization we we don't have one registry, but we have many registries as well working with docker hub.

B

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 to 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.

A

B

Let's say I want to re 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. We give people access to manage these repositories and.

C

B

They can themselves add delegation keys, remove delegation, keys, etc from those repositories.

A

Right, I think one of the things that we were trying to do with notre dame v2 uh was split, the registry from the uh signing component right um and so rather than going having like an ovary uh per registry.

A

um I think the approach here turns into you have like a single service, that's telling you essentially uh which public keys to trust and which, like delegates, have been revoked uh 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.

A

They can also define uh registry independent keys, so, like they'll, say here's the keys that I trust, uh and regardless of whichever registry you're pulling containers from uh you can validate against that. um I think this enables us to do things like uh uh migrate containers from one registry to another. um I think you know, as I've been fleshing out some of these use cases, uh what it's kind of making it more clear for me is what does the rather than the key management service?

A

What's almost like a key sharing service, look like in terms of how am I sharing my root public keys with others?

A

I I think that's kind of like a component that uh notary, like the notary server aspect of it, is almost turning into uh where, rather than hosting signatures, it's hosting for, like you, know, uh here's my developer identity here are my public keys and here's the keys I've revoked so far.

B

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?

B

How can we ensure that uh a team can self-manage their delegations.

A

I think that's one where we will 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 on creating delegate keys. uh I think this comes. This is something we'll need to flush out more in terms of how are those delegate keys created right um right now?

A

I think what I have spelled out here is just the steps that need to get taken. um I think there's a very good call-out that you're saying in terms of like you know, if you want this to be a centralized service, how would that operate?

A

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, um then really it's a matter of wherever the root public keys are being stored, uh that you can get the um uh the you haven't. You have access to kind of go, get those signed to get whatever you need sign for delegate key to be chained to the root key, um so I can add, I think, some steps in there that calls out.

A

I think this would be line 38, sorry line 39. The publisher creates new delegate, keys and local machine to change your root key. I think that one can get flushed out more in terms of what the design there would look like where, if you can specify where these root keys are stored.

A

Based on some identity access management, you can go. Get your delegate keys, signed by their root key.

B

So so I was thinking in our situation. We we have clients where the there is a requirement that, for example, they they cannot connect to the internet.

B

So with with this solution, that means there is one notary server somewhere in the cloud. um So what about? If, if this client needs to run a notary server in their internal network, but they still need to be able to pull images from from docker hub, for example, um so.

A

I think the the key management aspect of it may not necessarily be done through notary. um I think the key man as in 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 notary would be something that you need for communication between the publisher and the deployer.

A

So here I think this goes more into the uh key management, and I think this is one where, if we 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.

A

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.

D

A

And there you may have multiple routes that you're, creating and giving like. You know, routes across different teams or different organizations right so.

B

A

The hybrid scenario flushing that out and how those keys are delegated we'll address uh the delegate key generation, but the notary essentially becomes the more of the like. You have a root key.

A

How is that root key available to people that are deploying to know that this is the root key for this publisher, and I think there will want to list out what the 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're, sharing uh sort of like anyone. That's you know, publishing containers publicly.

A

um There can be notary servers that potentially are hosted in air gap regions right. um 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 uh what the notary server is changing into, because the nordi server today is hosting all these signatures, which I don't think is needed.

A

uh It really needs to become more of a root, key store and a revocation uh 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 um and that's one of the things I think we want to flush out, uh because I have. I actually have I'd, also like to get your thoughts on sort of like you know, uh when we do, for example, the local key store right.

A

Are we go? 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? uh 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.

B

So um yeah, what I was thinking is, if, if so so, I am just talking about the web interface makes it more tangible, especially for users or people who need to use this in a bigger organization. Who are not that deep into the topic.

B

So let's say we have a web application which integrates with the uh the enterprise single sign-on system. uh Based on that uh this web application, we can define some role-based access, control on different features, and there.

A

B

People can just define okay, for this repository a b and c uh is allowed to publish images, so that could be.

C

B

Jobs but also individual individual developers, um and similarly, we should also be able to remove those keys and um yeah to prevent that anyone randomly creates those uh repository keys. We could, for example, uh limit that to some kind of admin user who who takes care of the that part, so that allows us.

C

B

Self service portal.

A

Yeah, I call that out in the keyboard, listen and revocation use cases um 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.

B

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 a registry, so for a internal registry we deploy this web application. We have as we we didn't made it in such way, yet that we can support multiple registries with another ev2 that probably isn't required, because the the keys will be reusable across registries.

B

So that's that's.

C

B

Publisher side, but what I'm still not entirely or what's still not entirely clear to me, is what what happens? uh Let's say I I now register which keys and which allegations are are in place.

B

um That's registered against this single notary server, because whenever I create those keys, we also communicate with another reservoir. So it's known to the notary server, but.

C

B

What if I now have this internal server um or this internal notary server?

B

How? How do we sync up different notary servers? Maybe air 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, we might just want to only run against this private registry, where we have published our own images.

B

So we can keep that in a closed network.

B

Environment so.

A

Right, I think the the the part about, like the delegate key chaining to the root um that information should be part of the signature right.

A

B

So the solution there is more or less like how it works with with tls certificates. uh For for securing uh your your https traffic. Is it that.

D

B

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, and that we installed those certificates like the root certificates intermediates. We installed that on the system and then, by definition, everything created underneath that um structure is trusted.

A

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 in terms of like you know. um Do we envision having this would be would be useful um because the question here comes in, like you know, what's the guidance that we give like you know, just create a new route or create a subordinate.

A

uh I think uh subordinate, like from large organization perspective, makes a lot of sense, because then you have different levels of control, right, yeah, and so I kept moving up an item because 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 uh the signature validation, uh independent of registry- um you can do this.

B

A

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.

A

Where um 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 uh as a spending mechanism as well.

B

Yeah exactly because in our research department I have also been looking at. For example, let's say: if you want to use modern technologies like http, server, push or grpc kind of services you you need to run them on tls, 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 self-signed certificates, which are not trusted everywhere.

B

C

B

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, intermediate 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.

C

B

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 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.

C

Of certificates.

B

They can self-manage, but production certificates- that's just a small set of uh company administrators who can create those kind of certificates. So we were thinking about making this more or less self-managed.

B

So then, I also looked into um let's encrypt and the acme protocol like how you can automate retrieval of those certificates and renewal and those kind of things.

B

So now we we are talking about moving more or less into this tls certificate kind of approach. um I was thinking, wouldn't it be smart if we would integrate with this acme protocol, where you can also benefit from from automation and standardized apis which which are already there done by let's encrypt and and others.

A

So there are um some concerns uh with acme um and um I think that's one we can discuss further. I think that's actually worth a conversation in terms of what are the kind of automations we'd want to put in place, and there could potentially be things in terms of like you know, whichever domain, you trust things like that and there's a few different approaches 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.

A

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, but I think yes you're absolutely right like exploring uh the different automation options and seeing if any one of those would make sense, I think that's something.

B

You can so what I do personally to get my certificates, for example, is I I own my personal domain, so I use the dns challenge so that allows me to just create also certificates for my local host.

B

I just update my host file, put, for example, my dns name in there, and I just request certificates for my local host part. So that's based on the dns challenge and now, let's, let's take this scenario where you have a ci job which takes care of signing your images and the ci.

C

B

Needs to get his own signing key so then it it might make sense to to securely uh 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 certificate, maybe based on some new acme challenge.

B

We could validate us that this ci job is allowed to do that and.

C

B

After this, this ci job finishes, then this certificate kind of expires automatically, meaning you can never leave certificates flying around on ci servers and stuff like that, which is, of course also a security risk.

A

Right, um I think they're, the uh one other component that does come in through some things like that is you'd also need to get a timestamp signature on that, and so 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.

A

uh So I think that's um that kind of automation could make sense. um I think that's one where, um let's add those two ideas to like, so I think the first one is the uh automation and then getting certs from sort of like a public ca uh and then the second one that we were looking at uh would be making sort of, like you know, short lived search. uh That uh makes sense for sort of like the ci uh uh cicd pipelines ray uh and then the short list starts.

A

I think they add, in sort of like an external time, stamp uh requirement um to make sure that you trust the uh the the validity period like signature was generated during the validity period. um 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 come up with the short presentation on the uh the different mechanisms we have for that. um So I know that we can do sort of like domain-based challenges.

A

We can also do sort of like cname configurations. I think the the one thing that comes in here, though, is now um to publish a container.

A

You also need to now own a domain right, and so whether we want to go down the road of domains or emails, I think there's a few different options we can explore. um I I want I'll bring in sort of like a more exhaustive list and we can run through those automation, options and see which ones make sense.

B

Yeah yep yeah, I think for for the rest. I think the the list is uh pretty complete, which you you are showing in this uh pr um yeah. So the thing we are mainly concerned about is: uh how do we manage those keys? How do we uh also revoke people when, when they are leaving the company or switching departments, uh so from that.

C

B

We were looking at it um 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 deployment of this to to manage many notary servers.

B

So the the only thing which yeah we need to check and notary v2 is then how the the synchronization of these things would happen. If there are many notary servers.

A

So I think uh what I'll do today is add in what um uh the notary server like what role it is serving here and kind of what the key management component is serving for uh within the publishing environment.

B

Right should just be a client on top of the notary server to uh to create those certificates, um so currently notary or docker trust they they store that in this local folder. That's.

C

B

We did with this web application, so this web application has its own local folder, where the keys are stored. Currently, um depending on on time, I I can get for that. I I could also do small poc to store the keys in um in hashicorp 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.

B

I I think that is that's already covered um yeah and the other thing we are currently investigating is uh what, if uh a developer loses uh his uh delegation key, he was the last guy who signed the image. uh How do we do the rotation and replace that key? So so we can still continue to release images.

A

Okay, um I think those are all great suggestions. um I'm gonna get those in by noon and share it in the slack channel uh and.

B

Then we can take.

A

uh uh A quick sort of like review uh with the larger audience on monday uh and see where everyone's at um do you, I think you, the the monday meeting time, usually falls out of regular hours for you right.

B

um I guess so let me check the calendar. Do you know the the time for that meeting.

A

B

That's 7 p.m. So it depends uh if my wife has to work she works with shifts, so I have to take care most of these times. I need to take care of my kid, which.

C

Is kind of her bad time.

B

uh It's kind of the time she needs to go to bed. So then.

E

I'm always busy.

B

Taking her to bed and.

B

So in in, incidentally, I can join probably, but I cannot not always tell that up front.

A

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 uh thanks for the feedback.

B

A

Those are all sort of like valid suggestions and so I'll work on incorporating those.

B

So do we also need to uh update a heck of the meeting notes.

A

Yeah go ahead and not the those meetings.

B

um No, I never used hackmd, so I only read the meeting notes, but let me see how this works.

B

I think we can also work together in those meeting notes right.

A

C

A

There's a pen icon, I think, on the left side, uh let me actually copy the meeting template.

C

uh By the way I just joined, I'm sorry for being late, we had a tap plus like standardization meeting that um took the full amount of time, and then some um it sounds like you guys might be. Wrapping up. Is that correct.

A

um Well, the meeting was scheduled for a full hour. uh I think uh marco usually needs to hop off, uh 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 that. So what I'm essentially doing is right now is I put out a pull request, so I was getting uh feedback on that. uh If you want to read through the pull request, we can go through it and I'll make some revisions, then for the audience on monday.

C

Great okay um 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, youtube, channel or where's. The document that we're looking at.

A

I just put it in this button again.

C

I got it: okay, yeah, I think zoom doesn't show me chat history before I logged in.

B

Unfortunately, um so estonia do, we did you take notes on the feedback and feedback I I gave or.

A

Yeah, I was taking it down on pen and paper because that was easier for me. I'm going to just add it to the hacknb notes.

E

B

So I I have to leave in a couple of minutes.

B

So I'll stay around for a couple of minutes till I have to leave.

C

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 again he said he was joining.

A

Sure um I think whatever is easiest like if you want to read for the whole one and then we can go through questions or uh whatever's easier. It's like I initially had planned on sharing this doc before the meeting which I didn't get unfortunately get a chance to so um either works for me.

C

I guess like one of the big questions I have relates to you, you talk about, like publisher, shares the key and um 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 uh public key.

C

um I'm just wondering if you can like.

C

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.

A

Yeah, I completely get that question and I think that's. One of the conversations I want to have with the group uh is identifying uh 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?

A

I think that's one of the key goals of 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.

B

A

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 materials store, and there are different options there that we need to talk through in terms of implications, but at a very high level.

A

Essentially, what this is saying is that um in the signing environment, these are the tasks that we need to take care of and in the deployment environment. Here are the tasks we need to take care of, um and then the part that we need to still flush out a little bit. More is what does that sharing mechanism? Look like that answer. The question.

C

It does in part um it's great because it's one of those answers that that wants me makes me want to ask like four other questions. So it's like it was perfect.

C

um The I guess, like you talked before about um like the the previous model, using something where um the um like. Basically, you said it was signatures rather than keys in in uh the previous tough model, and can you just tell me a little about what you mean there.

A

So with the notary, v1 right, um you are when you're querying the notary server, um you are getting a uh as I understand the implementation.

A

You are getting uh all the different uh sort of uh signature files right um or the the target json the root json, the timestamp json right. So those are all analogous to certificates and signatures.

A

um I think the shift that would make a little bit more sense is if you move more into the model of trusted roots and trusted intermediates uh and have the uh individual signatures for the images uh be transported with the containers themselves right um and so that's kind of like what um I was envisioning would make the uh the container image sharing much more easier in the sense that uh the the the signature for the container itself would move with the container.

A

But then the the trust uh sort of like roots and intermediates and revocation lists would leave live more in sort of like the centralized service. If you will.

B

A

B

This summarizes it's more relying 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, is that a correct understanding.

A

Yeah, it would be something analogous to that yeah.

C

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 um we didn't go that route with with tough.

C

um um But I want to like trish chunk has now joined, um and I wanted to have a like 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.

C

In that you can't really have multiple people sign the same thing and the signatures are also separated 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.

C

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.

C

It wasn't really built with like.

C

I I I feel like I'm, not I'm not explaining this in a convincing way, like I almost feel like. I need a like a white board 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 trishank. Are you on the call yep?

C

Okay, um 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 backyard and talking trash, and I don't I'm not trying to do that. um I I just want to I. 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.

D

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 files themselves, because you're missing contacts about who did what that's the first thing I do agree.

D

The second thing is again: I I don't want to talk without missing uh by missing having missed a lot of contacts, 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 the 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.

A

I I agree with that feedback and I think, uh in terms of setting context, this is really the first time we're looking at this more detailed doc, and so uh 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 uh at scale.

A

Obviously, and revocation is obviously one of the tricky parts uh when you go into sort of like a sort of like trusted, root, configured model right rather than sort of like having the entire uh sort of like signature map available, so I think, there's trade-offs on either side. uh I think the question here is really highlighting these trade-offs and identifying um what makes sense. So I think any of the feedback here is absolutely welcome.

A

The way. The approach that I was kind of thinking of this more was triggered less around sort of like you know. Yes, uh the roles do matter. I think here the roles are classified more in terms of the uh the roots and the intermediates uh that is telling you who actually signed uh the artifact in terms of like you know whether you're trusting a company, in which case you might trust a root.

A

uh If you're trusting sort of like individual developers, those could be individual intermediates, um we can go up and down the tree and sort of like you know, make this uh 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 a trust root configuration.

A

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. uh What do we gain by either model? um And what are the changes I think uh part of uh where we want to take? This is uh one the core requirements that come in is that the notary server uh needs to be independent of registries. So you could use the same notary across multiple registries uh and the other part of it.

A

I think that's the core requirement uh is uh you know the the aspect of like you know, notary servers, potentially being private and public and uh being accessible.

A

I think outside of that, how the pki is set up, how the signatures are set up, I think, is something that's open for discussion, so um this is kind of like I think, like a starting point, so um I'd like to get sort of like pushback in terms of like what we see as the concerns here uh and how those are potentially addressed in something in more potentially like even a hybrid solution, if you will, but um uh if we start from there.

A

um I think uh what are the concerns here uh and, let's see, if we can't figure out how to address them, does that sound, fair.

D

Yeah, that is, that is wonderful. Thank you. In fact, some of some of your use cases you talked about, such as trust roots, 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 um and, and it's a fair question about what we gain by, not so by associating signatures directly with files, instead of different, different different roles right this sort of indirection.

D

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.

D

B

Okay, so uh neos. In the meantime, I uh I wrote down um 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 captured everything we discussed in the first half of this meeting.

A

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.

B

So I'll have to drop off now, but um yeah just keep me posted uh I'll, just check slack uh on a daily basis and if anything is required for my sites. Just let me know.

A

Sounds good. Thank you.

B

D

D

So nia sorry, I also missed some contacts about so where is it best to collaborate on this document? Is it on the github repository.

A

uh Yes, uh if you can provide comments there, we can go through that uh that way. 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 god, thanks yeah, I apologize I didn't have enough. uh I didn't get to stop then early enough, where I could share it earlier in the slack channel. I'm gonna try and get revisions out on wednesdays, uh going forward.

D

Oh no worries I mean I apologize, I didn't go. Do it myself.

C

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 a publisher, shares the root public key, so other users can verify the containers before running them.

C

But really um you know your goal is the thing in parentheses and the the you know like I'm, 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,.

C

C

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.

C

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.

C

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, I guess- and I might guess correctly, but I'm I'm not sure, I'm guessing right.

A

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 uh of container images with the root keys, because uh the root key is essentially translating into a root identity right uh and if the root key is readily available, then uh potentially it is something that could be easily compromised.

A

um There are sort of like implications around sort of, like you know, like you're having to more frequently update routes or more frequently kind of like rotate your routes and get that information out.

A

So one of the things that I was kind of thinking about here was that you know if we come up with a key architecture where the root key is not something you can use to sign images with, uh and you potentially have to use a delegate key for signing.

A

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?

A

uh One of the things we could potentially leverage here is, we could add in a key store requirement where right now, I believe in notary the keys are kept in a folder uh 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, um and if the root key isn't being frequently used.

A

Then really, you know uh it's really the delegate key that if you potentially gets compromised, in which case in case you could just you know, uh rotate that create a new delegate key uh and use that, uh and so that's kind of like where, uh uh where I was thinking about that, where uh we would now actually require everyone to kind of use, a.

D

A

Keeper's mining.

C

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.

C

It's something like we we've seen a lot of big organizations where, basically, they 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, um yeah.

C

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.

C

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, um 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 um doing something like tough and I'm trying to figure out like where the gaps are in the solutions.

C

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.

A

I think that's actually a fair call out. um I think I can actually elaborate on why these different steps are being taken.

B

A

They're accomplishing and, um like frankly, like you know, if there's a better story for getting the revocation information out in terms of liking, if you'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 uh sort of like framework currently works. I think there's potentially a hybrid there and I think uh you've actually called that one of the uh concerns that we had with notary v1, where to get a root rotation.

A

You have to sign with the old group right, and so if that route 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 group revocation look like versus what does a delegate revocation look like, I think, if we can build in sort of like automation, um 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.

A

What I'll do as a next step here is, is adding some of the motivations and I think, you're absolutely right like that, will make that conversation much easier. um What I'm gonna do is uh we only have like a few minutes left.

A

um I I'm gonna, take in sort of like the suggestions, I've gotten here uh and and and make some changes to the pull request and push it out today uh and then um I'm gonna 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 discussion.

A

Awesome. Okay, yeah was there any other comments that come up uh and that I could potentially.

D

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.

C

Yeah, I feel, like I kind of need that level of clarification before I. I can thrash and kind of add comments, but I don't want to do that. I'd rather have like a.

A

C

A

Yeah, I'm gonna post uh in the slack channel once I have the comments added in so feel free to take a look at the request. After those written.

D

Okay! Wonderful! Wonderful! Thank you! Thank you! Nias for, for.

C

D

This it's a very badly needed meeting.

C

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 us. We can make this meeting.

A

uh Yeah no worries, I think I have to change the meeting in my time as well. I think, like uh marco's, 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.

D

A

D

A

So we'll keep this hour going, uh but thanks for coming in and giving the feedback, I think all of it's very useful.

C

Thank you for being so gracious about it as well. um Awesome all right! Well, we'll see you uh in the next meeting. Hopefully all right sounds good. Have a good weekend see.

E

E

E