Project: in-toto (Provisioning / Security & Compliance)
File: review_1_december_20.md

We're past the first evaluation period of our [roadmap for 2021](https://github.com/in-toto/in-toto/blob/develop/roadmap-reviews/2021/ROADMAP.md) and it is time to do a review of how the in-toto reference implementation is holding up to its goals for this year. In this document, we will cover the activities from August to December 2020 in the context of the goals for this ROADMAP as well as other newsworthy developments. Our main objective of last year's roadmap was to tie down the public API for a 1.0.0 release. While we successfully revised the better part of the in-toto interface and corresponding documentation, one remaining issue spilled over into the 2021 roadmap, that is a clean-up of the utility and keys module (see ). Thus, we are all the more excited to announce that during this first 2021 roadmap review period we were able to sort out that remaining issue and publish in-toto 1.0.0. Compared to the previous version 0.5.0, which we published last fall, in-toto 1.0.0 includes better API and usage documentation, a more intuitive interface to handle cryptographic keys, and a few useful small features (the has the details). But above all, it is a commitment to the maturity and stability of the in-toto reference implementation. 1.0.0 release (on and on ) (official docs) Closed issues and merged pull requests Stable API () Replace utility module with revised securesystemslib key interface (, ) Update securesystemslib key interface (, , ) Strengthen securesystemslib key interface tests (, ) Mark Lodato (@MarkLodato) and his Binary Authorization team at Google are championing two new ITEs that generalize the in-toto link format () and the metadata signature wrapper shared with the TUF implementation (). The latter has become the corner stone for a new singing specification to be shared with the in-toto sister project TUF (see recent [organization roadmap review](https://github.com/in-toto/docs/tree/master/roadmap-reviews/2020) for

To leverage this momentum we are revising our in-house crypto library securesystemslib, which will become the reference implementation for the new signing specification, and have created a GitHub milestone that gathers issues on the path towards version 1.0.0. This milestone includes similar items as we had for in-toto 1.0.0, such as a clear definition of the stable API plus corresponding documentation overhaul. In addition, we are adding more flexibility on signing implementations by adding an abstract signing interface, and have explored minor inconsistencies in cryptographic key formats which we aim to consolidate. Revise architecture for stable API () Overhaul docs () Consolidate key formats () public key metadata format () stand-alone on-disk key format () in-memory key representation () Abstract signing interface () A key requirement for our reference implementation is its readability. This both helps integrators to adopt our concepts, and, as we believe, also has a strong positive impact on the security, correctness, and robustness of the software. On these grounds we have spent great efforts on revamping our [code style guide](https://github.com/secure-systems-lab/code-style-guidelines/blob/master/python.md) to align with current best practices in Python software development. And as good open source citizens we have upstreamed a feature for the Sphinx doc tool that enhances custom API documentation as prescribed by our new style guide. Kudos to our student assistant Yuanrui Chen (@SolidifiedRay), who spear-headed that development. Update code style guide () Further customize Napoleon Sphinx custom sections () Given the solid foundation that we have built with in-toto 1.0.0, we can now, with good conscience, explore new ideas and experiment with new features. As indicated in the 2021 roadmap, this will first and foremost include the implementation of custom ITE-4 artifact resolvers. In parallel we will push forward the realization of the designs for an enhanced Secure Systems Lab signature wrapper for in-toto and TUF as discussed in ITE-5. And last but not least we will continue to tighten the development and release procedures for the project, with the goal of earning the CII best practice gold badge.