# CNAB Security WG Meeting
**Meeting time:** Every other Wednesday 9:00 AM - 10:00 AM US Pacific Time
**Zoom Link:** https://zoom.us/j/653255416
**GitHub Repo:** https://github.com/deislabs/cnab-spec
**Group slack channel:** #cnab @ cloud-native.slack.com (Get an invite from: https://slack.cncf.io)
**Mailing list:** https://groups.google.com/a/opencontainers.org/forum/#!forum/dev
**Document Link:** https://aka.ms/cnab/meeting
**YouTube:** https://www.youtube.com/playlist?list=PLL6BzOBDywQeaaKFZkdt10JTZr5BxjQvQ
## Meeting Minutes and Agenda
## **Oct 23rd Agenda - Security and Registry**
| | |
| -------- | -------- |
| Recording | |
| Attending | |
| Note Taker | |
* New people?
* Demos?
**Agenda**
* updates on the security specification:
- [#301](https://github.com/deislabs/cnab-spec/pull/281)
- [#304](https://github.com/deislabs/cnab-spec/pull/288)
* [Signy](https://github.com/engineerd/signy) does thick bundles and handles credentials properly for generic registry / notary pairs
* we're looking for people to help a Python implementation of the security spec, if you want to help, let us know
* the work in `cnab-to-oci` SIGNIFICANTLY simplified the dependencies going forward for all Go projects
* OCI Spec - sync
**Notes**
* Trishank discussed 301
* Radu discussed 304
* Radu wants help on Python implementation for 304
* Trishank volunteered
* Radu: where to get in-toto root layout signing key from?
* Trishank: maybe just reuse TUF root key for now
* Trishank: we can also reuse Notary support for Yubikey to keep this root key
* Radu: TLDR - we want an implementation-independent spec that uses TUF and in-toto for CNAB Security (300)
* Silvin: we should discuss how to merge `cnab-to-oci` with CNAB Registry (200)
* All registries seem to break with `cnab-to-oci` right now
* We should write the Distribution spec now even before we get all the approvals from OCI
## **Oct 9th Agenda - Security Meeting**
(Deferred because most stakeholders could not attend.)
## **Oct 3rd Agenda - Security Meeting**
| | |
| -------- | -------- |
| Recording | [Zoom](https://datadog.zoom.us/recording/share/PWEIdNRUP0n7sbjCTcZmxZcjBe6ZUpIpi9fgOxlyr6OwIumekTziMw) |
| Attending | Ralph Squillace (Microsoft), Chris G (Microsoft), Justin Cormack (Docker), Radu M (Microsoft), Trishank K Kuppusamy (Datadog) |
| Note Taker | Trishank, Ralph |
**Rough minutes**
* Ralph: even within Microsoft, there will be very different customer demands. So flexibility will be key.
* Radu: do we want to prescribe how root keys for TUF and in-toto should be managed?
* Talk about how to distribute in-toto and TUF root keys
* Talk about possibilities
* Ralph: make clear what is necessary and what is not to achieve a desired level of security.
* Radu: could the targets key be used?
* Talk about how to use Notary v1 to just use top-level targets role metadata to sign everything.
* **Zoom chat**
* From Me to Everyone: (12:06 PM)
[https://github.com/deislabs/cnab-spec/pull/253](https://github.com/deislabs/cnab-spec/pull/253 )
* From Ralph Squillace to Everyone: (12:07 PM)
Apologies; there is a call that MIGHT be coming for me for which I need to step out.
* From Ralph Squillace to Everyone: (12:10 PM)
ralph: my position would be that we need to be flexible about this as well. Our example implementations can take one or another direction. My two cents. We should be clear that I understand Steve’s issues, but do not share them in all cases. We have enough customers that will demand something quite different.
* From Ralph Squillace to Everyone: (12:12 PM)
the complexity of discussion might map well to “levels of security” concept… I may have to step away… Which is a good concept to address. justin’s annoying with good questions that way I think we need to take a stance on it.
* From Me to Everyone: (12:17 PM)
[https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/](https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/)
* From Me to Everyone: (12:18 PM)
[https://dd-integrations-core-wheels-build-stable.datadoghq.com/metadata.staged/targets.json](https://dd-integrations-core-wheels-build-stable.datadoghq.com/metadata.staged/targets.json)
* From Ralph Squillace to Everyone: (12:20 PM)
Notes here: Justin, also how would the end user get the public keys as well how in PRACTICE you get the root layout key? Answer: we’re hijacking tuf for that
* From Radu M to Everyone: (12:27 PM)
Same here
* From Justin Cormack to Everyone: (12:27 PM)
sorry verr bad connection i was saying it depends on how much you want the spec to be generic or specific
* From Ralph Squillace to Everyone: (12:29 PM)
right ^^^
* From Justin Cormack to Everyone: (12:29 PM)
i think we need specific guidance eventually before people can reasonably use it
* From Ralph Squillace to Everyone: (12:29 PM)
ralph: want the spec to call out specific areas where a solution MUST be chosen in order to ACHIEVE a certain level of confidence, without saying WHICH solution is the one to choose.
* From Ralph Squillace to Everyone: (12:30 PM)
I also think that our example implementations MUST show one mechanism to do it. Better, two mechanisms. @Justin? ^^^^
* From Justin Cormack to Everyone: (12:30 PM)
its kind if hard to do that with security though, being vague leaves gaps that can break model
* From Ralph Squillace to Everyone: (12:31 PM)
I think we can work with this. I’d like to get as specific as we possibly can before we start moving into specific implementations. I think we can iterate with you here to reach workable and helpful levels of clarity We can call it the Justin Gut-Check(TM) ?????
* From Justin Cormack to Everyone: (12:32 PM)
i would prefer a set of fully worked out implementations
* From Ralph Squillace to Everyone: (12:33 PM)
I expect that those would be our “reference” implementations, yes. Are you saying we should move those implementations into the spec?
* From Ralph Squillace to Everyone: (12:34 PM)
I’t a reasonable take, I’m just confirming that we have a target in common, which I **think** we do, but just circling here.
* From Justin Cormack to Everyone: (12:34 PM)
well either the spec should be quite unspecific (this is how you add metadata). or it should include a list of reference implementations in more detail. i worry about in between stage.
* From Ralph Squillace to Everyone: (12:38 PM)
Radu’s work is a fantastic way to exercise this stuff Thanks, Justin — I appreciate the clarity for our work here.
Sign in with Wallet
Connect another wallet