## Current Meeting Notes

https://hackmd.io/@lukpueh/ry_e70Qqw

## 11/04/2022 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* SCORED next week
* in-toto Spring Cleaning / Reorganizing community onramp
* KubeCon NA retrospective
* ContribFest
* Verifiable SBOMs
* Next steps for ITEs
* ITE-7 https://github.com/in-toto/ITE/pull/34
* Attestation Maintainers report

### Attendees
* Aditya Sirish (NYU)
* Ian Dunbar-Hall (Lockheed Martin)
* Mikhail Swift (TestifySec)
* Trishank Karthik Kuppusamy (Datadog)
* Andres Torres (VMware)
* Marina Moore (NYU)
* Parth Patel (Kusari)
* Marcela Melara (Intel)
* Santiago Torres-Arias (Purdue)
* Mark Lodato (Google)
* Lukas Puehringer (NYU)

### Notes

- SCORED Reminder:
- SCORED is happening next Friday, co-located with CCS

- Spring Cleaning:
- We noticed during the ContribFest that the organization of in-toto may confuse newcomers as to where to start
- Some previous discussions with Lukas and Marcela regarding what structure could be helpful.
- Specifics:
- Community repository:
- Essentially where we point people new to in-toto
- Clearly separate out the two specifications we have (spec + attestation)
- Help guide people on how to contribute to those specs
- Code of conduct, governance, attestation maintainers, maintainers
for implementations and so on
- Santiago: Is this automatable?
- Lukas: comes from a conversation with Joshua Lock on how they do
it with the TUF org. They put something together for the TUF org
that was never fully realized. It was based on a template from the
CNCF. Includes a whole governance process with a steering
committee and such.
- https://github.com/cncf/project-template/blob/main/GOVERNANCE-subprojects.md
- Kubecon Updates:
- Maintainer's track talk:
- some demos (related to ITE-4 + the keylime demo)
- Contribfest:
- Joined with TUF and Sigstore
- "90 minute slot for people to contirubte and welcome people who
are new to the project and hack away"
- Had some spec, doc, and more questions whose PR were merged and
have been merged.
- Some changes to ITE-7 as a result of some discussion (to be
described)
- in-toto github action contributed by Cole Kennedy and Mikhail
from TestifySec
- Verifiable SBOMs:
- Basic idea: can we use in-toto semantics to expand the
information that the scannner provides and can we stick this
information inside of an in-toto layout.
- Goal: can we both get an SBOM and benefit from an end-to-end
software supply chain security from the in-toto framework.
- link to document:
https://docs.google.com/document/d/1sojT2WnbJLDeDPid5FFRAK6Ue4Pu8WEm4kDtxVSTIGM/edit#heading=h.rkcco9c4imnh
- short term goal: define a specification
- Idea: use in-toto (maybe TUF) as building blocks, but the idea is
to have it a standalone project
- Mark: question: is the idea to generate an sbom using verifiable
information? answer: goal is to ensure whatever the scanner gave you is the
right information.
- Mark: point: make sure that the SBOM is complete. Scanner may not
know that some elements are missing. The direction may be
friendlier to a "hybrid approach" so as to reduce the
signal-to-noise ration.
- Ian: is there a meeting scheduled? answer: not yet, but there should be
one soon.
- Changes to ITE-7 (Mikhail)
- Primary changes are about how we should be handling the trust bundles (i.e., a collection of certs).
- Overloading key object in the in-toto spec.
- Instead: change it to a generic trust bundle in the same way that
OpenSSL does: a list of PEM-encoded x509 certificates.
- This will require a couple of changes in -golang
- Feedback needed!
- Aditya: Document itself is in good shape. Perhaps merge as accepted
in December community meeting.
- Also, we may want to consider the fulcio usecase in ITE-7.
- Changes to verification language:
- Santiago: we may want to move on to CUE/OPA, or something with a
different DSL. We may also want to re-think the way that we handle
the specification
- Trishank: We need to do more due diligence around what the
requirements are. Have things changed since the initial release of the
policy language?
- Mark: there are different levels of agreement between consumer and
producer. There are also additional checks that *certain* consumers
may want to do. The latter are probably worth considering separately.
For the first case, it may be simpler for them to take the already
defined language. e.g., maybe the organization may say: before you
deploy run these checks.
- Lukas: to add: artifact matching rules aren't being used as widely as
they could be. They are quite complicated and that may make them hard to
adopt. Perhaps a standard dsl that may make things better.
- Mark: we need to come back to user journeys to help develop a target
design would help. This would help us taylor the solutions.
- Aditya: How would this complexity map to distinct predicates? How
would this tie back into this? We probably want to tie this back into
a separate working group that focuses on this problem.
- Parth: Kyverno is likely moving to CUE, so this is something worth
considering.
- Santiago: keep 1.x working with current verification language (and
accomodate ITE-6) and start preparing a 2.x release that handles the
new verification language
- Attestation Repo:
- 5 new people agreed to help manage the attestation predicates.
- Parth: so far they've had two meetings to discuss the runtime attestation
type. This week, the SCAI predicate proposed by Marcela (attestations that
describe attributes for a specific artifact, and provide evidence). E.g.,
can you prove that something builds hermetically by combining the runtime
and the SCAI attestation?
- Marcela: SCAI: attribute-focused supply chain metadata. Other metadata
(e.g., SBOM) focus on describing things about an artifact. However, a
piece that is missing is a descriptor about the artifact's capabilities.
For example, compilation may vary depending on the flags you use. Certain
binaries may change instrumentation on the IR representation. These
changes may change the properties of the resulting artifact.
Question: Can we capture information about what the supply chain is *doing* in
order to change the behavior of an artifact? We want to be able to *know*
exactly *how* this something came to be. The SCAI predicate can also let
you know things about a producer (e.g., this producer is using a hardware
enclave from a hardware attestation).
- Parth: GUAC: we ingest SCAI attestations and make decisions like: "can I
run this in a prod environment, or is there not enough evidence"

## 10/07/2022 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* in-toto + Keylime (Mark Bestavros)
* Runtime Trace attestations (Parth Patel)
* Ideas for in-toto / TUF / Sigstore ContribFest at KubeCon
* in-toto Specification Next Release
* Is it time for v1.0?
* What's the process for backwards incompatible spec updates in future?

### Attendees
* Lois Anne DeLong (NYU)
* Andres Torres (VMWare)
* Mikhail Swift (TestifySec)
* Trishank Karthik Kuppusamy (Datadog)
* Justin Cappos (NYU)
* Santiago Torres-Arias (Purdue)
* Aditya Sirish (NYU)
* Mark Bestavros (Red Hat)
* Parth Patel (Kusari)
* J K
* Marcela Melara (Intel)
* Shripad Nadgowda (Intel)
* Bob McW

### Notes

Prior to the actual start of the meeting, Justin shared some notes on a supply chain security meeting he attended this week. One thing he noted is that participants seem to have a rather narrow definition of what constitutes threats against supply chains.

A rep from Yubico (creator of YubiKeys) mentioned the article Trishank wrote about Yubikeys to Justin at the meeting, so there is awareness in the community of our work (though the person did not mention TUF or in-toto by name)

Trishank echoed the limited parameters individuals within the field seem to set when it comes to supply chains. He noted that dependencies appear to be the biggest concern in this arena. Also, the concerns are always about OTHER people's supply chains, not their own.

#### New community member introductions (if any)
* Mark Bestavros of RedHat briefly introduced himself.

#### in-toto + Keylime (Mark Bestavros)
* Keylime, a CNCF project, is a run-time hardware backed system that "provides a highly scalable remote boot attestation and runtime integrity measurement solution."
* Mark presented a demo of how Keylime with in-toto works.

#### Runtime Trace attestations (Parth Patel)
* Over the past few weeks a team led by Parth Patel has been capturing runtime trace information so, in the future, policy checks can be made.
* Parth shared a predicate model for these traces currently in development.
* By the next in-toto meeting he will have more to report.
* He is hoping that this can eventually serve as a standard.
* A question was asked as to whether there may be a confidentiality risk in this method that needs to be addressed. This concern can be modified/addresed by using other tools that can keep this information internal.
* The attestations are currently formulated specifically for builds. It can be made generic, but this is not an option currently being pursued.
* SLSA attestations can be collected alongside the runtime attestation, but such an option would bloat the data size.
* What is the point of generating verifiable attestations if the current output is for internal purposes only? This remains an open question.

#### Ideas for in-toto / TUF / Sigstore ContribFest at KubeCon

* No immediate interest expressed

#### in-toto Specification Next Release
* There is a need to address the backwards compability issues before considering a V.1.0 release.
* Also, existing ITEs would need to be reviewed to determine which would be included in V.1.0. One such issue is What about the signature wrappers.

## 09/09/2022 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* GSoC 2022
* ITE-9: in-toto/attestation maintainers
* Supporting multiple versions of SLSA provenance (Chuang Wang)
* https://github.com/in-toto/in-toto-golang/pull/177
* New home for adoptions and integrations -- Add yours!
* https://github.com/in-toto/friends

### Attendees
* Lois Anne DeLong (NYU)
* Aditya Sirish (NYU)
* Santiago Torres-Arias (Purdue)
* Michael Lieberman (Kusari)
* Justin Cappos (NYU)
* Thomas Richter (Control Plane)
* Chuang Wang (Google)
* Lakshya Gupta (GSoC)
* Parth Patel (Kusari)
* Reza Curtmola (NJIT)
* Joshua Lock (VMWare)
* Yuanrui Chen (NYU)
* Sebastien Awwad (Anaconda)
* Sangat Singh Vaidya (NJIT/Qualcomm)
* Trishank Karthik Kuppusamy (Datadog)
* Preston Moore (Anaconda)
* Marcela Melara (Intel)
* Pradyumna Krishna (GSoC)

### Notes

#### New Community Member Introductions
* None

#### GSoC 2022
* Lakshya Gupta presented a few slides summarizing his research project in updating the Jenkins plug-in and adding SLSA provenance. He also shared a demo of the work.
* Pradyumna Krishna also summarized his work with DSSE in securesystemslib and in-toto-python. He noted that he had been able to complete his required tasks.

#### ITE-9: Vote on in-toto/attestation maintainers
* Data on the winners can be found at https://civs1.civs.us/cgi-bin/results.pl?id=E_b792e888a5e3ecbf
* There was an issue of not wanting to have two maintainers from the same company. As a result, the winners were:
* Marcela Melara (Intel Labs)
* Joshua Lock (VMWare)
* Tom Hennen (Google)
* Mikhail Swift (TestifySec)
* Parth Patel (Kusari)

#### Supporting multiple versions of SLSA provenance (Chuang Wang)
https://github.com/in-toto/in-toto-golang/pull/177
* The purpose here is to be able to maintain multiple versions of slsa-specific statement struct especially when slsa v1 comes out in next couple of months.
* The proposal is to revert slsa0.1 back to help the community evaluate the model of keeping multiple versions.
* There is a need to coordinate these efforts with SLSA
* Also, backwards compatibility needs to be raised as an issue.

#### New home for adoptions and integrations
https://github.com/in-toto/friends
* New way of displaying/tracking current and emerging integrations.
* It can track HOW the companies are using in-toto.
* It was suggested that the link add logos or other information to make the adopters/integrators more visible at a glance.

## 08/05/2022 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Next steps for selected ITEs
* GSoC 2022 Updates
* ITE-9: Confirming in-toto/attestation maintainers
* Distributing public key parameters for root layouts (Trishank)

### Attendees
* Lois Anne DeLong (NYU)
* Santiago Torres-Arias (Purdue)
* Tom Hennen (Google)
* Joshua Lock (VMWare)
* Lakshya Gupta (GSoC)
* Parth Patel (Kusari)
* Mike Lieberman (Kusari)
* Trishank Kuppusamy (Datadog)
* Mark Lodato (Google)
* Andres Torres (VMWare)

### Notes

#### Next steps for selected ITEs
* Three ITES are currently in Draft form: ITE 6, 7, 9
* Sponsors for ITE 7 and 9 were not present for this meeting, so only ITE 6 will be addressed.
* ITE 6 (https://github.com/in-toto/ITE/tree/master/ITE/6) is currently stalled because some predicate types are overlapping. If variations are introduced, how are they classified?Can users just add extra fields without changing predicate types?
* How easy do we want to make it for users to make multiple small changes? Could this yield compatibility problems down the road?
* On the flip side, how easy is it to create new predicate types?
* The group agreed to approve the existing ITE and open a new one that dealt with this issue of how to handle variations.

#### GSoC 2022 Updates
* One of the GSoC contributors was present and reported on his work in solving issues with the Jenkins plug-in.
* Some security concerns were raised about the Jenkins source file.

#### ITE-9: Confirming in-toto/attestation maintainers
https://github.com/in-toto/attestation/issues/98
* Need to establish a team of maintainers to review potential predicates.
* Some people have already volunteered to work on this project. Parth Patel volunteered at this meeting.
* How many maintainers do we need?
* Attendees agreed it would be good to have one reviewer from each project.
* Recommendation was to have at least three reviewers. The names will be confirmed at the September meeting.

#### Distributing public key parameters for root layouts (Trishank)
* New proposal, particulaly for public repositories,identifies a gap between how TUF describes keys.
* One possibility is to embed the TUF keys in the in-toto metadata. This borrows from how ITE 2 works.
* It would create a way to accommodate the number of different crypto systems used.
* Possibly address this by creating a new ITE that supercedes ITE 2.

#### Miscellaneous notes
* How does SPDX relate to in-toto attestations?

## 07/01/2022 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Next steps for selected ITEs
* ITE-6
* Type system for attestations?
* ITE-7
* ITE-9
* GSoC 2022 Updates
* Coordinating in-toto-golang's support for older SLSA provenance versions (Chuang Wang)

### Attendees
* Lois Anne DeLong (NYU)
* Trishank Kuppusamy (Datadog)
* Andres Torres (VMWare)
* Santiago Torres-Arias (Purdue)
* Mike Lieberman (Kusari)
* Adam Shamblin (VMWare)
* Chuang Wang (Google)
* Aditya Sirish (NYU)
* xynnn
* Pradyumna Krishna (GSOC)
* Lakshya Gupta (GSOC)
* Joshua Lock (VMWare)

#### Next Steps for ITEs

##### ITE-6
* Already has several implementations to support it.
* Next step would be to get the community to establish what would be the minimum required material for submitting an attestation type. This is where ITE-9 comes in.
* ACTION ITEM More examples of attestation implementations are needed so we can test how they work. Set up a section/subsection where these examples can be posted for review

##### ITE-7
https://github.com/in-toto/ITE/blob/master/ITE/7/README.adoc
* This was held at the last meeting because none of the sponsors were present.
* Aditya posted a PR at https://github.com/in-toto/ITE/issues/33 proposing the ITE be accepted.

##### ITE-9
https://github.com/in-toto/ITE/pull/32
* Already been discussed at a few meetings this year and is probably ready to be merged as a draft.
* The purpose of the ITE is put the mechanisms in place for establishing the process for submitting attestation types.
* Thread for this has been established on the Slack channel
* The ITE was merged as a draft during the meeting.

#### GSOC Updates
* Pradyumna Krishna noted some issues with Python TUF.
* Lakshya Gupta is working on updates of Jenkins plug-ins to add provenance extension.

#### Other Business
* Chuang Wang asked if SLSa .2 will have backwards compatibility issues for in-toto golang.
https://github.com/in-toto/in-toto-golang/pull/156
* The thought about the above is not to worry about backwards compatibility until SLSA 1.0 is released. "Just support the latest version you can."

## 06/03/2022 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Roadmap Review draft
* https://github.com/in-toto/docs/pull/62
* Next steps for selected ITEs
* ITE-6
* ITE-7
* ITE-9
* GSoC 2022

### Attendees
* Lois Anne DeLong (NYU)
* Aditya Sirish (NYU)
* Pradyumna Krishna (GSoC)
* Lakshya Gupta (GSoC)
* Santiago Torres-Arias (Purdue)
* Andres Torres (VMWare)
* Mark Lodato (Google)

### Notes

#### Roadmap review
(https://github.com/in-toto/docs/pull/62)
Comments?
* This is a bit overdue for merging, but will be done in the next few weeks.
* Please send comments on any needed changes

#### ITE Update

##### ITE 4
* Yuanrui Chen, a student at NYU, and Alan Chung Ma, of Purdue, have been working on developing resolvers for ITE-4 entities.

##### ITE 6
* At the last meeting, it was noted this ITE was close to acceptance, but a few things still need to be resolved.

##### ITE 7
* None of the sponsors for this ITE were present.
* Santiago will touch base with the sponsors to check on any possible roadblocks.

##### ITE 9
* Aditya will begin working on this again next week and both ITEs 6 and 9 can be discussed further at the next meeting.
* There is a question of whether ITE 9 will register and store the different attestation types or whether a separate repository should be built for this purpose.
* Need to distinguish between registry and non-registry items.

#### GSoC 2022
* in-toto will host three GSoC contributors this summer. Two of them are present at the meeting.
* Lakshya will be working on adding provenance support for the Jenkins plug-in.
* Pradyumna will be working on some of the issues associated with ITE 5, specifically on DSSE capabilities for the Python reference implementation.

## 04/01/20222 Meeting

### Call Information
* 11 AM **EDT**
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Concerning YOLOchecks on all major repositories
* ITE-9 updates
* Changes since last meeting
* CNCF Incubation official!
* Next steps for selected ITEs
* ITE-6
* ITE-7
* Google Summer of Code
* https://github.com/cncf/mentoring/blob/main/summerofcode/2022.md#in-toto
* Project 1: Jenkins + SLSA + in-toto
* Project 2: rebuilderd + SLSA + in-toto
* Project 3: DSSE support for in-toto-python
* COSE Signing for in-toto-golang
* Volunteers needed!

### Attendees
* Aditya Sirish (NYU)
* Lakshya Gupta
* Andres Torres (VMWare)
* Santiago Torres-Arias (Purdue)
* Wiktor Kozlik (Google)
* Mark Lodato (Google)
* Lois Anne Delong (NYU)
* Pradyumna Krishna
* Sergio Felix (Google)
* Yuanrui Chen (NYU)
* Cole Kennedy (TestifySec)
* Trishank Karthik Kuppusamy (Datadog)
* Marcela Melara (Intel Labs)
* Kate Stewart (SPDX)

### Notes

#### Welcome to new attendees
* Lakshya Gupta -- applicant for a GSoC project
* Pradyumna Krishna --also a GSoC applicant

#### SLSA compliance
* Should we be working toward increasing our ranking by working on SLSA attestations?
* If we were to produce these attestations, where would they be hosted?
* https://reproducible.seal.purdue.wtf/
* Maybe having a neutral API would make more sense than conforming to one particular format
* There is an open SLSA issue here:
https://github.com/slsa-framework/slsa/issues/269
* There was a recommendation that we could use this issue to "gather the folks who are interested in this topic?" (Quote from Mark Lodato)
* A designated repo could be established to serve as an informational hub where people could research what is out there
* ACTION ITEM--Use the issue mentioned above to begin coalescing opinion and comment.

#### CNCF Incubation official!
* in-toto is now an incubating project.

#### ITE-9 updates
* https://github.com/in-toto/ITE/pull/32
* This would establish a process for registering/adding new attestation types.
* Aditya summarized what this process might entail:
* definition
* rationale
* document type modeled on the SLSA provenance
* He mentioned the use of discussions in these community meetings as an important step in deciding on these attestations
* There should be a pre-defined list/schema for these types
* There is a need to acknowledge how this fits with ITE 5 (https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc)
* New attestations would still need to conform to the in-toto spec and with the attestation spec https://github.com/in-toto/attestation/blob/main/spec/README.md#envelope
* Is this PR being written to meet a specific use case? Or is it all about being "future compatible"

#### Next steps for selected ITEs
* ITE-6: probably can be merged next time
* ITE-7: Open a PR to accept this--put the issues in for discussion and see what happens

#### Google Summer of Code
https://github.com/cncf/mentoring/blob/main/summerofcode/2022.md#in-toto
* Project 1: Jenkins + SLSA + in-toto
* Project 2: rebuilderd + SLSA + in-toto
* Project 3: DSSE support for in-toto-python
* COSE Signing for in-toto-golang
* Volunteers needed!
* Lakshya asked if there was a template that needed to be used for that submission
* Santiago emphasized that in-toto cares more about the content of the proposal and not the format

## 03/04/2022 Meeting

### Call Information
* 11 AM EST
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* ITE for introducing new attestation types
* https://github.com/in-toto/ITE/pull/32/files
* CNCF Incubation
* Next steps for selected ITEs
* ITE-6
* ITE-7

### Attendees
* Lois Anne DeLong (NYU)
* Aditya Sirish (NYU)
* Andres Torres (VMWare)
* Mikhail Swift (TestifySec)
* Mark Lodato (Google)
* Yuanrui Chen (NYU)
* Santiago Torres-Arias (Purdue)
* Wiktor Kozlik (Google)
* Marcela Melara (Intel Labs)
* Bob Martin (MITRE)
* Cole Kennedy (TestifySec)
* Trishank Karthik Kuppusamy (Datadog)

### Notes

#### ITE for introducing new attestation types
https://github.com/in-toto/ITE/pull/32/files

* The pull request introduces the idea of formalizing how new attestation types are developed, documented and introduced. It's goal is to streamline the process of how these attestation types are introduced and evaluated.
* There was a consensus that the ITE be more specific about the problem it seeks to solve. For one thing, there is a need to clarify the ITE is about the process. It is not the place where any specification would live.
* Perhaps the ITE should mention the need for a central repository of approved attestation types.
* Also, are the attestations that go through this site implied as "blessed" by in-toto?
* Aditya noted that he has updated the PR to reflect some of the comments from this discussion.
* Attendees also recommended specifying the scope of the PR.
* Perhaps store the predicate schemas in a central repo, such as the attestation repo, and the ITE process can focus on *changes* to those schemas.
* Some of this work may be dealt with in a proposed GSOC project.

#### CNCF Incubation
* Incubation has been approved, based on our count in the vote thread.
* We hope to hear about it publicly next week.

#### Moving forward on ITEs

##### ITE-6
* Currently in draft stage.
* Should be accepted before we move on to ITE 9, as there is some overlap.
* There are still three fields that may require some additional iteration/discussion.
* Could we break backwards compatibility and just re-do the layout to include different attestation format?
* in-toto 2.0.0 could include this different format, while the existing format could be maintained for those who do not want to upgrade.

##### ITE-7
* Would support signing and verifying link metadata with key & X509 certificate pairs.
* It is being used in production in one instance.
* * SigStore might serve as another use case for this ITE.
* One problem lies in what happens when short-lived certificates "outlive" their time.
* In the future, a new timestamp would need to be added.
* As currently described this ITE does not deal with the problem of short-lived certificates.
* Validating short-lived certificates might be better addressed in a separate ITE.

## 02/04/2022 Meeting

### Call Information
* 11 AM EST
* https://meet.jit.si/in-toto-community-meeting

### Agenda

* ITE-2 Acceptance
* https://github.com/in-toto/ITE/issues/26
* ITE Workflow (Logistical) Improvements
* Human Review Attestations
* Applies to code review, as well as any other human reviews such as threat models etc
* Currently working on defining what policies would look like for such attestations, seeking feedback / ideas
* Also interested in incorporating crev-like attestations for dependency reviews/audits
* https://github.com/in-toto/attestation/issues/77
* CNCF Incubation
* Public comment period is open, vote should be coming up soon
* https://lists.cncf.io/g/cncf-toc/topic/in_toto_incubation_public/88521779
* Witness Demo (TestifySec)

### Attendees

* Aditya Sirish (NYU)
* Lois Anne DeLong (NYU)
* Cole Kennedy (TestifySec)
* Andres Torres (VMWare)
* Yuanrui Chen (VMWare)
* Bill Weinberg (TestifySec)
* Santiago Torres-Arias (Purdue University)
* Mikhail Swift (TestifySec)
* Mark Lodato (Google)
* Wiktor Kozlik (Google)
* Sergio Felix (Google)
* Dan Chernoff (Contino)
* Marcela Melara (Intel Labs)
* Kate Stewart (SPDX)
* Tom Hennen (Google)

### Notes

* Started with introductions of newcomers

#### ITE Workflow (Logistical) Improvements

* Plan is to use community meetings to advance the status of ITEs by determining the things that might be holding things back.

#### ITE 2 Acceptance
(https://github.com/in-toto/ITE/issues/26)
* Has been open for some time (2019). There doesn't appear to be anything blocking its acceptance.
* A question was raised as to "what does acceptance of an ITE mean?" General consensus was that it means the community is ready to stand behind the content as a recommendation, rather than a requirement
* The ITE was accepted. https://github.com/in-toto/ITE/pull/30

#### ITE 7
(https://github.com/in-toto/ITE/pull/21)
* Also up for approval as a draft
* Merged as draft

#### Human Review Attestations
(Current Attestation types listed at https://github.com/in-toto/attestation/#introduction)
* Applies to code review, as well as any other human reviews, such as threat model, etc.
* Currently working on defining what policies would look like for such attestations, seeking feedback / ideas
* Also interested in incorporating crev-like attestations for dependency reviews/audits
(https://github.com/in-toto/attestation/issues/77)
* Should we collect use cases in a doc and see how the implementations would apply to them?
* This could be done by having "conversations" to collect case studies
* Perhaps devote a set period of time at community meetings to discuss these issues and keep it moving forward that way.
* The question was raised as to why we do not just use the ITE process? The answer was "because we want to move things along faster" However, there was some agreement that approaching this through ITEs might be worth a shot. It was proposed that some use cases be run through the ITE process to see if this is a feasible way to handle things.
* May need to more formally establish how these attestations would work.
* Marcela Melara indicated interest in this thread / issue because human reviews is an interesting use case.
* A "construction of predicates" is needed. Perhaps we should provide a minimal framework on which others can build?
* Where should these definitions should be stored? Is there a need for a centralized repository? There probably should be a "blessed version" on the in-toto repository for the community as a whole, while other projects can post their own as needed.
* There is also a need to have some way to share review types.

#### CNCF Incubation
* Public comment period is open, vote should be coming up soon
(https://lists.cncf.io/g/cncf-toc/topic/in_toto_incubation_public/88521779)
* We should have been up for a vote this Monday, but it was moved back to next Monday.

#### Witness Demo (TestifySec)
(https://github.com/testifysec/witness)
* Just switched the repo to public today.
* Uses ptrace to record artifacts consumed by a compiler for example.
* Policy defines what attestations are expected.
* Subjects are wrapped in in-toto statements
* Built from the ground-up since October. Worked to maintain compatibility with in-toto implementations
* Can we add a layer so individual projects don't have to build their own versions?

## 12/03/2021 Meeting

### Call Information
* 11 AM EST
* https://meet.jit.si/in-toto-community-meeting

### Agenda

* ITE-2 up for acceptance
* We should perhaps set a date for comments, and allow ITE editors to make a decision
* https://github.com/in-toto/ITE/issues/26
* ITE-6 updates
* Discussing code review (crev project) and SPDX attestations
* Exploring the idea of a generic "review" attestation to derive from for CRs, vulnerability scans and so on
(https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md)
* TestifySec

### Attendees
* Aditya Sirish (NYU)
* Mark Lodato (Google)
* Cole Kennedy (TestifySec)
* Mikhail Swift (TestifySec)
* Andres Torres (VMWare)
* Lois Anne DeLong (NYU)
* Tom Hennen (Google)
* Santiago Torres Arias (Purdue)
* Marcela Melara (Intel)

### Notes

#### ITE 2

* It was proposed that a date should be set for comments on this issue, and that ITE editors should go ahead and make a decision
* The issue has been around since 2019.
* Are there any stumbling blocks to acceptance? If so they can be presented here https://github.com/in-toto/ITE/issues/26

#### ITE 6
https://github.com/in-toto/ITE/blob/master/ITE/6/README.md
* This ITE "defines a new schema for in-toto link files, which are now generally called 'attestations.'' The proposed ITE "allows users to define their own custom 'predicates' with arbitrary schemas. This makes it easier and more natural to express any type of metadata about software."
* Currently looking into the idea of a generic "review" attestation that can be derived from CRs, vulnerability scans and so on
* There was discussion about the code review (crev project) and SPDX attestations
* Discussion of how in-toto attestations can work more effectively as SBOMs. See https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md

#### Witness
* in-toto implementation that includes ITE 5 and 6
* Git information about commits etc. can be saved as attestations
* Makes it possible to track particular statements/commits.
* All Open source
* Looking to release it after the first of the year.
* Can do multiple predicates signed as a unit
https://github.com/in-toto/attestation/blob/main/spec/bundle.md
* Proposal to create an issue to discuss this further.
* Rekor materials should be available as a demo shortly
* Policy is essentially the same as in-toto.
* Schema of the output is directly tied to the tool that created it.

#### Next Meeting
* January 7?

## 11/05/2021 Meeting

### Call Information
* 11 AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* Meta (not that one)
* Plan to make meetings regular, likely every four weeks / first friday of every month
* Two ITEs since last meeting
* [ITE-3](https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc)
* [ITE-5](https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc)
* [ITE-2](https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc) up for [acceptance](https://github.com/in-toto/ITE/issues/26)
* ITE-6 / in-toto Attestation updates
* Mention type usage, and possible new additions (e.g., hardware root of trust, sgx workload attestation, etc.)
* ITE-7
* Certificate semantics, enables SPIFFE integration
* in-toto-golang includes support, courtesy of BoxBoat / IBM contributors
* ITE-8
* Proposal to create a library for in-toto layouts / policies
* in-toto-java refactored
* Adds DSSE support
* https://github.com/in-toto/in-toto-java/pull/24 merged!
* 0.4.0 will be cut soon

### Attendees
* Aditya Sirish (NYU)
* Tom Hennen (Google)
* Andres Torres (VMWare)
* Lois Anne DeLong (NYU)
* Mikhail Swift (TestifySec)
* Lukas Puehringer (NYU)
* Santiago Torres-Arias (Purdue)
* Joy Liu (UPenn, in-toto GSoC 2021)
* Mic Bowman (Intel)
* Reza Curtmola (NJIT)
* Mark Lodato (Google)
* Parth Patel (BoxBoat)
* Dan Chernoff (Contino)
* Sergio Felix (Google)
* Andy Martin (ControlPlane)
* Marcela Melara (Intel)
* Hammad Afzali (Microsoft)

### Notes

#### Meeting Frequency
* Meetings will be held the first Friday of every month
* Next meeting: December 3

#### ITE Updates
Discussions and status quo updates on existing ITEs

##### [ITE-2](https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc) up for [acceptance](https://github.com/in-toto/ITE/issues/26)
* Proposes a compromise-resilient way to securely distribute, revoke, and replace the public keys used to verify the in-toto layout.
* To do so, it integrates TUF to "add to the repository a higher layer of signed metadata.""

##### [ITE-3](https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc)
* Accepted.
* Details Datadog's integration of TUF and in-toto
##### [ITE-5](https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc)
* This would divorce the signature mechanism from the in-toto specification, enabling adopters to generate in-toto metadata using other formats, perhaps in wireline formats they already support.
* Accepted.

##### ITE-6 / in-toto Attestation updates
* This ITE "defines a new schema for in-toto link files, which are now generally called 'attestations.'' An attestation is authenticated metadata about one or more software artifacts. Instead of a fixed schema (materials, products, command, etc.), the attestation format allows users to define their own custom 'predicates' with arbitrary schemas."
* One Example: SLSA Provenance (https://slsa.dev/provenance), a claim that some entity (builder) produced one or more software artifacts (Statement’s subject) by executing some recipe, using some other artifacts as input (materials).
* Current model in ITE-6 offers three distinct layers each representing trust in different things. Is there some way to be less rigid as to what goes into these layers?
* https://openssf.org/blog/2020/11/06/security-scorecards-for-open-source-projects/
* https://github.com/ossf/scorecard
* Mention type usage, and possible new additions (e.g., hardware root of trust, sgx workload attestation, etc.)
* Hardware root of trust would have some proof that it came from trusted hardware.
* Can we build stronger trust in the builder, as opposed to the hardware?
* See short whitepaper from Intel on high-integrity SW supply chain work: https://arxiv.org/abs/2106.09843
Published at this summer's NIST Workshop on SW Supply Chain Security.

##### ITE-7

* Certificate semantics enables SPIFFE integration
* in-toto-golang includes support, courtesy of BoxBoat / IBM contributors
* Spire PR for review -
https://github.com/in-toto/in-toto-golang/pull/147
* Current implementation in SPIRE the signing keys is verified through the SPIRE server. It means the user no longer needs to worry about the keys themselves
* The ITE could use more reviews on the Pull Request to see how it might work in other applications.
* A note about the process...ITEs often linger too long before becoming drafts. Is there a way to get to draft quicker and iterate from there?

##### ITE-8
* This proposes creation of a library for in-toto layouts and policies
* Opened as a PR, no text has been merged as draft as of yet.
* This could be a Google Summer of Code project for next year.

#### in-toto Java implementation
* in-toto-java refactored
* Adds DSSE support
* https://github.com/in-toto/in-toto-java/pull/24 merged!
* 0.4.0 will be cut soon
* Sergio Felix will be joining the team as a maintainer of in-toto-java

## 08/27/2021 Meeting

### Call Information
* 11AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* Roadmap Reviews to close final 2021 evaluation period
* [in-toto/docs review](https://github.com/in-toto/docs/blob/master/roadmap-reviews/2021/review_3_july_21.md)
* [in-toto/in-toto review](https://github.com/in-toto/in-toto/blob/develop/roadmap-reviews/2021/review_3_july_21.md)
* New Roadmap
* https://github.com/in-toto/docs/blob/master/ROADMAP.md
* Google Summer of Code
* Joy Liu
* https://crates.io/crates/in-toto/0.1.1
* rebuilderd can now generate in-toto links!
* https://github.com/kpcyrd/rebuilderd/pull/65
* ITE-5 and DSSE
* https://github.com/in-toto/ITE/blob/master/ITE/5/README.md
* https://github.com/secure-systems-lab/dsse
* https://github.com/in-toto/ITE/issues/22
* ITE-6 and in-toto Attestation
* https://github.com/in-toto/ITE/blob/master/ITE/6/README.md
* https://github.com/in-toto/attestation
* ITE-7 by BoxBoat
* Mikhail Swift
* https://github.com/in-toto/ITE/pull/21
* https://github.com/boxboat/in-toto-golang
* SCIM Collaboration
* Kay Williams
* https://github.com/microsoft/scim
* Refactoring of in-toto-java
* https://github.com/in-toto/in-toto-java/issues/23

### Attendees
* Aditya Sirish (NYU)
* Cole Kennedy (TestifySec)
* Reza Curtmola (NJIT)
* Sangat Singh Vaidya (NJIT)
* Mikhail Swift (Boxboat)
* kpcyrd (Reproducible Builds / rebuilderd)
* Sebastien Awwad (Conda)
* Trishank Karthik Kuppusamy (Datadog)
* Christian Rebischke (Arch Linux / in-toto)
* Kay Williams (Microsoft)
* Santiago Torres-Arias (Purdue)
* Joy Liu (GSoC / in-toto)
* D Niu (Datadog)
* Wiktor Kozlik (Google)
* Tom Hennen (Google)
* Sergio Felix (Google)

### Notes

#### New roadmap

* in-toto's next roadmap primarily looks at progress in the context of the different ITEs that have been proposed

#### GSoC Report

* Joy discussed her work on in-toto-rs to add in-toto-run functionality
* Mentioned open PR for rebuilderd integration
* Santiago provided more context to the community about what rebuilderd does and kpcyrd's work in the space
* Mentioned that future work on the in-toto space includes work on the apt transport

#### ITE-5

* Santiago provided an overview of what ITE-5 / DSSE are
* The backward compatibility discussion: Trishank and Santiago discussed some points about how to transition from the old wrapper to DSSE on the reference implementation
* Route to acceptance thread open for another 2-3 weeks

#### Minor Diversion: GitHub vs Mailing List

* Developers may be more comfortable using GitHub for ITE-related discussions over the mailing list

#### ITE-6

* Allows for specific types for attestations
* Used by SLSA for provenance
* Want to include proof of reproducibility, SBoMs etc
* A process for people to submit attestation types
* Santiago went over the idea of ITE-6, and the differences between the new style attestations and current links and layouts
* Also currently used by Tekton Chains
* Some discussion about vuln scans as a type
* Still a WIP
* Some folks want to use their own policy engine with these attestations
* Possibly in-toto verification module for OPA
* How do in-toto layouts verify attestations?
* Under discussion, via inspections possibly

#### ITE-7

* Mikhail described ITE-7's addition of PKI support to in-toto
* Mikhail also gave an overview of what SPIFFE does
* One PR: https://github.com/in-toto/in-toto-golang/pull/119/
* Two more coming: adds CLI, adds SPIFFE integration

#### SCIM Collaboration

* Kay Williams presented about the overlap of SCIM and in-toto
* SCIM = Supply Chain Integrity Model

## 04/22/2021 Meeting

### Call Information
* 11AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* Roadmap Reviews for evaluation period ending in April 2021
* Release of in-toto v1.1 at the end of April 2021
* SPIRE integration with in-toto-golang (Cole Kennedy of BoxBoat)
* Integration of in-toto with Clair
* ITE-6
* SigStore support for ITE-6 enabled rekor types
* ITE-5, release of Signing Spec v0.1.0 and roadmap to v1.0

### Attendees
* Hammad Afzali (NJIT)
* Yuanrui Chen (NYU)
* Dan Chernoff
* Reza Curtmola (NJIT)
* Chris Erway (Solarwinds)
* Trishank Kuppusamy (Datadog)
* Joy Liu (UPenn)
* Joshua Locke (VMWare)
* Mark Lodato (Google)
* Andy Martin (ControlPlane)
* Frederic Pierrat (QubesOS)
* Christian Rebischke
* Trevor Rosen
* Tom van Shwerdiner
* Aditya Sirish (NYU)
* Santiago Torres-Arias (Purdue)
* Sangat Vaidya (NJIT)
* Kate Stewart (SPDX)
* Carlos

### Notes

#### Roadmap Reviews for evaluation period ending in April 2021 and
* Aditya Sirish committed the latest draft of this document a few days ago. It reviews activities from January to April 2021, which includes the release of a patch 1.0.1 release of the Reference Implementation. This is the final release offering support for Python 2.
* The review also points to progress on ITEs 5 and 6,

#### Release of in-toto v1.1 at the end of April 2021

#### SPIRE integration with in-toto-golang (Cole Kennedy of BoxBoat)
This discussion was postponed because the responsible people could not be with us.

#### ITE-6
https://github.com/in-toto/attestation
* ITE-6 defines the in-toto attestation format, which represents authenticated metadata about a set of software artifacts. Attestations are intended for consumption by automated policy engines, such as in-toto and Binary Authorization.
*
* Mark Lodato a change ITE-6 to say "use this new attestation format"
* A 0.1 release will be labeled next week, so that we can refer to specific versions

#### SigStore support for ITE-6 enabled rekor types
* Provide support for rekor types which helps to support a broad signature space.
* Was presented as a project for people who might be interested in getting involved with the in-toto projects

#### ITE-5
* Proposes switching to a new signature envelope in in-toto, namely the SSL Signing Spec. Instead ofwhich can now only focus on describing in-toto specifics, rather than cryptographic building blocks.
* Merged as a draft earlier this week
* Chris Erway reported on a colleague's WIP ITE-5 implementation at https://github.com/solarwinds/in-toto-golang/pull/2, noting that the implementation will depend on the envelope structure defined in the ITE-6 PR. He mentioned that the envelope could be moved to the ITE-5 PR if that makes more sense.

#### Other questions/comments

* A question was raised about timelines for acceptance of ITE 5 and 6 as V.1.0. The response was that both had been accepted as drafts (Lois: Is this true? ITE 6 is not listed on the master ITE page.)
* Frederic Pierret of QubesOS shared an update on his rebuilder project (https://github.com/fepitre/debian-snapshot-mirror)

## 02/11/2021 Meeting

### Call Information
* 11AM EST
* https://meet.jit.si/in-toto-community-meeting

### Agenda

* First release of in-toto-golang
* https://github.com/in-toto/in-toto-golang/releases/tag/v0.1.0
* Roadmap Reviews for end of December 2020
* https://github.com/in-toto/in-toto/blob/develop/roadmap-reviews/2021/review_1_december_20.md
* https://github.com/in-toto/docs/blob/master/roadmap-reviews/2021/review_1_december_20.md
* Updates about Signing Spec and ITE-5
* https://github.com/secure-systems-lab/signing-spec
* https://github.com/in-toto/ITE/pull/13/
* ITE-6
* https://github.com/in-toto/ITE/pull/15
* SPIRE integration with in-toto-golang (Cole Kennedy of BoxBoat)
* NYU Reproducible Builds Rebuilder
* https://r-b.engineering.nyu.edu

* Python 2.7 support in reference implementation
* Grafeas + in-toto
* https://github.com/in-toto/totoify-grafeas/pull/3
* https://github.com/in-toto/totoify-grafeas/pull/4

### Attendees
* Aditya Sirish (NYU)
* Lois Anne DeLong (NYU)
* Frédéric Pierret (QubesOS)
* Santiago Torres-Arias (Purdue)
* Yuanrui Chen (NYU)
* James Higgins-Thomas (Fiserv)
* Gerard Borst (Rabobank)
* kpcyrd (rebuilderd / Arch Linux)
* Andy Martin (ControlPlane)
* Lukas Pühringer (NYU)
* Wiktor Kozlik (Google)
* Trishank Kuppusamy (Datadog)
* Mark Lodato (Google)
* Jim Gettys
* Fredrik Skogman
* Nenad Dedic (Google)
* Chris Erway (SolarWinds)
* jk (?)
* Cole Kennedy (BoxBoat)
* Mikhail Swift (BoxBoat)
* Kate Stewart (SPDX)

### Notes

First release of in-toto-golang
https://github.com/in-toto/in-toto-golang/releases/tag/v0.1.0

* In process for about three years
* Google Summer of Code student worked on it last summer
* Pre-release version has been posted.
* Used by kubesec:
* Inital version in Cloudrun on GCP.
* Can do initscripts that will not lock it into one application
* Sits in the GitHub market as an action

#### Roadmap Reviews for end of December 2020

[[reference implementation review](https://github.com/in-toto/in-toto/blob/develop/roadmap-reviews/2021/review_1_december_20.md), [org review](https://github.com/in-toto/docs/blob/master/roadmap-reviews/2021/review_1_december_20.md)]

* Released in the middle of January, based on activity status in December.
* A lot of activity on the ITE front, particularly ITE 5 and 6
* Also information on status Grafeas. Put together a tool that can store in-toto data on Grafeas implementation
* The tool has been released
* For the reference implementation--stable 1.0.0 release completed
* Have a tool that can generate in-toto layouts recently released I missed that we've been improving our layout creation tools since the summer. The improvements we've made were deployed to in-toto.engineering.nyu.edu

#### Updates about Signing Spec and ITE-5
* python-securesystemlib not in a stable state to port to Golang yet
* Perhaps initially do this in Python before implementing it in other languages, or develop in go based on signing-spec, indepentently of python-securesystemslib
* signing-spec is actually very simple: How do you sign a blob generically

#### ITE-6
https://github.com/in-toto/ITE/pull/15
* Specifics are not fully settled yet, including the actual mechanisms
* Introduces "ad hoc semantics"
* Keeps generic links for agility
* Accomodates both generic links and ad-hoc
* Extending a requests for ideas and comments
* Impt goal--that it not be "in-toto specific"...aiming for more of a standard than a specific "in-toto" approach
* Implementations?
* Can perhaps adopt existing programs?
* Perhaps develop a "plug-in" system for these specs?
* "a minimum specification"
* Still in early stages, so its a

NYU Reproducible Builds Rebuilder
https://r-b.engineering.nyu.edu
* Santiago wants to host a version at Purdue
* Does anyone else in the community want to comment? Now is a good time to do so

Qubes Rebuilder
https://github.com/fepitre/package-rebuilder
https://github.com/fepitre/rpmreproduce

#### SPIRE integration with in-toto-golang (Cole Kennedy of BoxBoat)
* Agent that sits on the machine and notes what processes are making the call.
* Through a backend process, it can identify and find the correct certificate
* Generates an entity and signing keys for ephemeral elements
* Using in-toto requires a complicated key management SPIFFE/SPIRE simplifies the process
* https://tools.ietf.org/html/rfc3161

NEXT MEETING?

Links in comments

https://r-b.engineering.nyu.edu

we can generate json/openAPI schema from protobuf.
https://github.com/secure-systems-lab/signing-spec/issues/18

## 12/01/2020 Meeting

### Call Information
* 11AM EST
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* Introductions
* The first 2021 roadmap review is due at the end of December, and we'll be going over the work our contributors have put in this period
* Release of in-toto 1.0
* Acceptance of ITE-4
* Updates on new, standalone signing-spec for use in in-toto and TUF
* Proposed ITE-6

### Attendees
* kpcyrd (rebuilderd / Arch Linux?)
* Christian Rebischke
* Aditya Sirish (NYU)
* Reza Curtmola (NJIT)
* Sangat (NJIT)
* Tom Hennen (Google)
* James Higgins-Thomas (Fiserv)
* Lukas Pühringer (NYU)
* Santiago Torres-Arias (Purdue)
* Hammad Afzali (NJIT)
* Gerard Borst
* Kristel Fung
* Mark Lodato (Google)
* Andy Martin (ControlPlane)
* Nenad Dedic (Google)
* Trishank Karthik Kuppusamy (Datadog)
* Kay Williams (Microsoft)
* Lois Anne DeLong (NYU)

### Notes
- Santiago gives overview of ongoing work in in-toto subprojects
- Kristel has been working on an [in-toto/Grafeas translation layer](https://github.com/in-toto/totoify-grafeas/pull/3)
- Christian has been working on the [in-toto go implementation](https://github.com/in-toto/in-toto-golang/), which might be interesting for [kubesec](https://github.com/controlplaneio/kubesec) folks. (Santiago briefly explains what kubsec is) Engineering resources for future in-toto-golang development are yet tbd.
- Similarly, the [in-toto rust implementation](https://github.com/in-toto/in-toto-rs) could use help. Santiago considers replacing the crypto provider, which seems to be a requirement for [rebuilderd](https://github.com/kpcyrd/rebuilderd). kpcyrd will verify that. (you can ping kpcyrd on `[e-mail]`)

- Lukas talks about 1.0.0 release of the in-toto python reference implementation, which is above all a commitment to the maturity and stability of the API. It also adds more intuitive key management interfaces and better documentation.

- Aditya talks about advances in ITE-4 since the last meeting. It has become accepted and the [CNAB](https://cnab.io/) community has started to experiment with it.

- One of the next steps for the reference implementation will be to add custom resolvers for [ITE-4](https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc) resources.

- Santiago mentions that we will likely start with resolvers for GitHub activities, like PRs, issues, etc.

- Gerard points out non-persistence of these resources and thus changing hashes. (This issue is also captured in [ITE-4#Dynamic-data..])(https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc#dynamic-data-in-remote-abstract-entities))

- Santiago and Gerard talk about resolvers for docker images or in a more generalized form [OCI](https://github.com/opencontainers/image-spec) images, and the possibility of using the hash that is already in the name

- Aditya talks about the history of the signing specification... how the Google/Binary Authorization team proposed a change to the in-toto signature wrapper metadata format (see [ITE-5](https://github.com/in-toto/ITE/pull/13)), how this was run by the [TUF community](https://hackmd.io/jdAk9rmPSpOYUdstbIvbjw?view#1020-Meeting), and has now become a stand-alone [specification](https://github.com/secure-systems-lab/signing-spec/blob/master/specification.md), to be adopted by both TUF and in-toto.

- Mark gives overview of signing-spec key features:
- canonicalization and parsing of untrusted data no longer required
- content type is can be read without parsing the payload but is also part of the authenticated message
- envelope content type makes it easier to use other formats than json (cbor, protobuf, etc. ), and to support different versions of formats

- Kay asks how this metadata format changes relate to SBOM work and Santiago explains upgrade paths and that a lot of thought was put into backwards compatibility

- Santiago gives overview of [ITE-6 - Generalized link format](https://github.com/in-toto/ITE/pull/15), also proposed by the Google / Binary Authorization team. Feedback from the community is welcome.

- Santiago and kpcyrd discuss delegation of trusted keys with sublayouts to make changing keys easier on different levels of the trust hierarchy.

## 09/15/2020 Meeting

### Call Information
* 11AM EDT
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* Roadmaps for 2021 [1][2]
* Releasing in-toto reference implementation 1.0.0
* Report from KubeCon Europe
* Further development of in-toto-golang through GSoC [3]
* ITE-2, 3, 4 updates and adoptions [4][5][6]
* in-toto + rebuilderd for Reproducible Builds and the birth of a rust implementation of in-toto [7][8]

[1] https://github.com/in-toto/docs/blob/master/ROADMAP.md
[2] https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md
[3] https://github.com/in-toto/in-toto-golang/pull/56
[4] https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc
[5] https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc
[6] https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc
[7] https://github.com/in-toto/in-toto-rs
[8] https://github.com/kpcyrd/rebuilderd/pull/22

### Attendees
- Aditya Sirish (NYU)
- Santiago Torres-Arias (Purdue)
- Lois Anne DeLong (NYU)
- Wiktor Kozlik (Google)
- Ivan Pedrazas (ControlPlane)
- James Higgins-Thomas (Fiserv)
- Justin Cappos (NYU)
- Trishank Karthik Kuppusamy (Datadog)
- Brandon Lum (IBM Research)
- Mark Lodato (Google)
- Joshua Lock (VMWare)
- Hammad Afzali (NJIT)
- Jack (ControlPlane)
- Sangat (NJIT)
- Reza Curtmola (NJIT)
- Kay Williams (Microsoft)
- Kate Stewart (SPDX / Linux Foundation)

### Notes

#### Roadmaps for 2021

https://github.com/in-toto/docs/blob/master/ROADMAP.md
https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md

* The new roadmap covers August 2020-August 2021 and was published on August 11th.
* The roadmap does NOT include a release announcement of v1.0.0 of the Reference Implementation, as it was decided that a few outstanding issues still needed to be resolved. The plan now is to release version 1.0.0. by the end of the year
* Accomplishments from the last roadmap included work on the Java Implementation and Jenkins plugin.
* Work for the year ahead will be focused on more stable implementations, and will include upgrading from a "Silver" to a "Gold" rating under the Core Infrastructure Initiative's best practices badge.
* Lastly, the authors look to ensure that the changes outlined in the three current draft ITEs can be integrated with existing technologies.
* Since ITEs 2 and 3 relate to TUF integration, we will make sure we have a tighter testing harness with co-dependent libraries (e.g., securesystemslib). In addition we will make sure common elements, such as public key components and signatures, can be cross-verifiable by both implementations.

#### Report from KubeCon Europe

* in-toto was mentioned in two talks at KubeCon Europe, building interest abroad.

#### in-toto-golang

* Christian Rebischke, a Google Summer of Code intern on the in-toto project, did some significant work on implementing a fully-fledged in-toto runlib in Go. Most of his contributions are summarized here: https://github.com/in-toto/in-toto-golang/pull/56.
* He also described his experience over the summer in two blog posts you can read at https://shibumi.dev/posts/google-summer-of-code-2020/ and https://www.cncf.io/blog/2020/10/07/gsoc-spotlight-my-google-summer-of-code-experience-at-cncf-in-2020/.
* Furthermore he proposed a few other PRs after his GSoC internship like multi hash support, Github Actions CI and gitignore like exclude patterns.

#### ITEs

There are three ITEs currently in draft stage.

##### ITE-4

https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc

This ITE changes the requirement that the identifier for each in-toto artifact must be its path in the filesystem. Instead, it would allow the artifact to have a generic Unique Resource Identifier (URI) in-toto specification (URI) that can be resolved to some external resource within the supply chain.

Aditya Sirish is spearheading efforts on this ITE.

* Now that it is a draft, Aditya is calling for input from the community to identify any weaknesses,
* A test prototype https://github.com/adityasaky/in-toto/tree/ite-4-cnab-resolver was developed for the workflow laid out in Use Case 3 for CNAB bundles. But, the authors are looking for volunteers to write prototypes for other applications.
* In addition to CNAB, other use cases cited as motivation for ITE-4 were the use of identifiers in SPDX documents, and a desire to provide attestations to the Pull Requests and Issues on GitHub.
* Proposal still holds the security promises for arbitrary artifacts that were presented in the in-toto USENIX 19 paper (https://ssl.engineering.nyu.edu/papers/torres-toto-usenix19.pdf).
* Kay Williams mentioned the use of purl (package URL - https://github.com/package-url/purl-spec) as something to consider as an identifying scheme within ITE-4.
* Aditya is reaching out to Brandon Lum to discuss a use case he is working on in container security to see if ITE-4 might provide a solution.

##### ITE-2 and 3

https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc
https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc

* Trishank summarized the issue these ITEs address, and shared the link to a DataDog blog post (https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/)that describes the combined use of in-toto and TUF.
* He also recommended considering support for things like HashiCorp Vault (https://www.vaultproject.io/) for industry bootstrapping.

#### Other news

##### **in-toto + rebuilderd and new Rust implementation**

* Santiago announced that there was a new implementation for the Reproducible Builds Community (https://github.com/in-toto/in-toto-rs).
* He has an open pull request (https://github.com/kpcyrd/rebuilderd/pull/22) on the rebuilderd repository that generates in-toto link metadata for rebuilder builds.

##### **Signature Wrapper / Signing Spec**

* Aditya described a new effort by the in-toto and TUF teams to extract the signature wrapper used by both projects and release it as a standalone spec.
* This will enable adoption beyond TUF and in-toto metadata.
* He asked the community to share any issues they may have with the current wrapper used in in-toto.
* Kay Williams asked about how this would tie in with the Software Bill of Materials effort (https://www.it-cisq.org/software-bill-of-materials/index.htm).
* Santiago agreed to send out more information on this initiative to those community members who want to get involved.## Roadmaps for 2021
https://github.com/in-toto/docs/blob/master/ROADMAP.md
https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md
* The new roadmap covers August 2020-August 2021 and was published on August 11th.
* The roadmap does NOT include a release announcement of v1.0.0 of the Reference Implementation, as it was decided that a few outstanding issues still needed to be resolved. The plan now is to release version 1.0.0. by the end of the year
* Accomplishments from the last roadmap included work on the Java Implementation and Jenkins plugin.
* Work for the year ahead will be focused on more stable implementations, and will include upgrading from a "Silver" to a "Gold" rating under the Core Infrastructure Initiative's best practices badge.
* Lastly, the authors look to ensure that the changes outlined in the three current draft ITEs can be integrated with existing technologies.
* Since ITEs 2 and 3 relate to TUF integration, we will make sure we have a tighter testing harness with co-dependent libraries (e.g., securesystemslib). In addition we will make sure common elements, such as public key components and signatures, can be cross-verifiable by both implementations.

## 04/20/2020 Meeting

### Call Information
* 11AM EST
* https://meet.jit.si/in-toto_community_meeting_20200420

### Agenda

* [ITE-2: Using TUF and in-toto to build compromise-resilient CI/CD](https://github.com/in-toto/ITE/pull/4)
* ITE-2 is an informational ITE on how to use TUF for securely distributing in-toto metadata files and the corresponding software packages.
* [ITE-3: Real-world example of combining TUF and in-toto for packaging Datadog Agent integrations](https://github.com/in-toto/ITE/pull/5)
* ITE-3 is an informational ITE that describes an implementation of the system described in ITE-2 by Datadog. This system is used to distribute Datadog Agent integrations in a compromise-resilient manner.
* [ITE-4: Supporting generic URIs for artifacts in in-toto](https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc)
* Current Status: ITE-4 has been accepted by the ITE editors as a draft
* ITE-4 proposes enhancing the in-toto specification to support abstract and/or remote resources as artifacts in the software supply chain. * Currently, the in-toto specification limits supply chain artifacts (materials and products) to files in the filesystems of the machines involved in the supply chain. ITE-4 primarily defines a URI format to refer to these resources and its behavior in the different parts of the in-toto workflows
* The ITE authors are seeking feedback from the broader in-toto community and there is currently one [ongoing thread on limiting abstract resources to static entities](https://github.com/in-toto/ITE/issues/7)
* [in-toto is now in Grafeas!](https://github.com/grafeas/grafeas/pull/391) in-toto is now a metadata kind in Grafeas and Grafeas instances can be used to store link metadata files.
* The Jenkins in-toto plugin is being updated with more functionality and will soon include support for Grafeas as a transport. The latter is currently a work in progress which can be tracked in this [PR](https://github.com/jenkinsci/in-toto-plugin/pull/10). As the Grafeas in-toto metadata format slightly differs from the standard in-toto format, a translation layer is being implemented in the plugin to perform the necessary conversions.
* Setting up rebuilders:
* current rebuilder constellation status
* [rebuilderd](https://github.com/kpcyrd/rebuilderd)

### Attendees
Santiago Torres-Arias, Moderator

Gerard Borst, Justin Cappos, Reza Curtmola, Adrian Diglio, kpcyrd, Trishank Kuppusamy, Joshua Lock, Radu Matei, Bryan Russell, Aditya Sirish, Ralph Squillace, Kate Stewart, Kay Williams

### Notes

#### Update on ITEs

Trishank Kuppusamy and Santiago Torres-Arias presented progress reports on three in-process ITEs (or in-toto Enhancements). Both ITEs 2 and 3 deal with how to use in-toto in tandem with TUF, with ITE 3 offering a specific use case of how the two programs were implemented together by DataDog. Trishank noted that ITE 2 is also relevant to Cloud Native Application Bundles, which facilitate the bundling, installing and managing of container-native apps, and is used in Microsoft Windows build effort. TUF is used to provide compromise-resilient, transparent distribution and rotation of the in-toto root layout public keys, and consistent snapshots. (Note: ITEs 2 and 3 were merged as drafts on May 5. Comments are invited)
ITE 2 https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc
ITE 3 https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc

Santiago reported that ITE 4 (https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc), which allows generic URI schemes to refer to abstract entities in in-toto metadata, such as GitHub PRs, has been adopted as a draft, but input is still being solicited.The ITE will likely be open for feedback and comments for at least two or three months.

#### Updates on Integrations and Implementations

Santiago announced that he will be working on developing an SPDX prototype over the summer.

*Grafeas/Jenkins*
Santiago also reported that [in-toto is now](https://github.com/grafeas/grafeas/pull/391) in Grafeas as a metadata type and Grafeas instances can be used to store link metadata files. The integration includes a Jenkins in-toto plugin that can gather information to be transferred to Grafeas.

Aditya Sirish described a pull request that proposes several changes to the Jenkins plugin, including “translation layers” that support the necessary conversions from in-toto formats to Grafeas metadata formats. The work is described [here](https://github.com/jenkinsci/in-toto-plugin/pull/10). Note that since the meeting, this pull request has been merged into the plug-in.

Bryan Russell of Google echoed the need to reconcile compatibility and architectural differences to allow in-toto data to be stored in Grafeas. He pointed to Google’s use of protocol buffers, or protobufs as a place where “translation” may be required.

Kay Williams of Microsoft mentioned performance issues as the largest concern and pointed to the need to “unmarshall JSON” as a way to address protobuf compatibility.

*Setting up rebuilders:*
Kpcyrd talked a bit about progress on the rebuilderd project, explaining that rebuilding requires three components, working together--a monitor, a scheduler, and a worker. The rebuilderd system offers “one-stop shopping” for these tasks. It allows verification of pre-compiled packages by repeating the build step in an identical environment, and then verifying that the package is identical. https://github.com/kpcyrd/rebuilderd

#### In-toto 1.0.0.--End of the Roadmap

Santiago noted that in-toto had reached the end of its one year Roadmap and asked if anything needed to be tweaked before it moves to 1.0.0. Trishank brought up the issue of parameter substitution, or a way to tell in-toto “I may not know the value of something ahead of time.” He asked if this might be a compatibility issue. Santiago agreed that the issue of parameter substitution should be included in V.1.0.0.

Santiago noted there was a need to make a push for any tooling required for inspection of containers.

*No immediate date was set at the time, but plans for the next meeting are currently being discussed. Look for an announcement soon.*

## 02/24/2020 Meeting

### Call Information
* 11AM EST
* https://nyu.zoom.us/j/513012224

### Agenda

- Update on the ROADMAP[1] progress, and plans for development for the last months of this ROADMAP year.
- Update on ITEs 2, 3 and 4. We think that Specially 4 should start moving [2][3][4]. forward soon, as it will be of particular interest for the OMG/CDF Software Bill of Materials work[5]
- Plans for KubeCon Europe!

[1] https://github.com/in-toto/docs/blob/7a9bed510dc5e291777cc60b4ba30dd44fc5a6ab/roadmap-reviews/2020/review_2_december_19.md
[2] https://github.com/in-toto/ITE/pull/4
[3] https://github.com/in-toto/ITE/pull/5
[4] https://github.com/in-toto/ITE/pull/6
[5] https://github.com/cdfoundation/sig-security-sbom

### Attendees
Santiago Torres-Arias, Moderator

Gerard Borst, Mynor Cifuentes, Reza Curtmola, Marc Evers, Tobias Furuholm, Jim Gettys, Juan Gomez, Jack Kelly, Jon Knox, Bart Kors, Trishank Kuppusamy, Adam Lewis, Joshua Lock, Andrew Martin, Radu Matei, Lukas Pühringer, Brian Russell, Jennie Steshenko, Aditya Sirish A Yelgundhalli, Lois A DeLong

### Notes

Note: We had some issues during our meeting with faulty acoustics and, as a result, these notes are not as complete as we would like them to be. We apologize for any discussion threads that were inadvertently omitted, or any incorrect statements. Please feel free to help us “fill in the gaps” by sharing on the thread. We will come up with a more reliable technology for our next meeting.

#### Roadmap

Santiago brought the group up to date on progress towards in-toto V. 1.0.0, which is scheduled for completion in April 2020. This included work on cross-implementation interoperability for in-toto golang and work with Debian to test the reproducibility of packages. The current progress report on the Roadmap can be found at

https://github.com/in-toto/docs/blob/master/roadmap-reviews/2020/review_1_august_19.md, and

https://github.com/in-toto/docs/blob/master/roadmap-reviews/2020/review_2_december_19.md.

Lukas talked about the remaining tasks for the v1.0.0 release of the reference implementation, which boil down to setting in stone a stable API and generating library documentation.

##### Deployments

Gerard Borst and Bart Kors from Rabobank, who have created a fork of in-toto called Argos Supply Chain Notary, described their ongoing progress with the system. This included a change to the layout and link metadata format with the goal of making it more JSON compatible, the addition of an expected final product field in the layout, and the removal of inspections.

https://github.com/rabobank/argos

##### ITE 4

Aditya talked briefly about his work on ITE 4, which allows generic URI schemes to refer to abstract entities in in-toto metadata, such as GitHub PRs (see https://github.com/in-toto/ITE/pull/6). He invited everyone to review and comment on the PR, which is relevant for collaborations with SPDX (Source Package Data Exchange) and GitHub.

##### in-toto jenkins plugin

Aditya also mentioned preparing a demo that uses the in-toto Jenkins plugin to publish attestations for the steps of a web app build pipeline in a Grafeas store, performing final product verification in an in-toto Kubernetes admission controller

(Note: Parts of that demo have been presented by Mark Russinovich, CTO of Microsoft Azure, at RSA Conference https://www.youtube.com/watch?v=tHwLCDrs1zQ&feature=youtu.be&t=2597)

##### Other Issues

There was some discussion about moving to a different meeting technology as this Zoom technology had issues, particularly with accessibility and background noise.

Lukas and Justin will attend KubeCon and each is scheduled to do a talk.

(Note: KubeCon Europe was postponed to July/August due to COVID-19)

There was a general consensus that posting on the in-toto mailing list might be the best way to initiate discussions of concern to the community. These discussions could then be moved to GitHub in the form of issues or pull requests as warranted.