notary + tuf proposal

proposals/notary + tuf.adoc

@@ -0,0 +1,191 @@
+== Notary & TUF Proposal
+
+*Name of project:* Notary & TUF
+
+*Description:*
+
+The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework.
+
+Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions. It is the de facto image signing framework in use by Docker, Quay, VMWare, and others.
+
+Notary and TUF have been presented at [CNCF TOC meeting 6/20/2017](https://docs.google.com/presentation/d/1MvCZytMQpTgGW4IvJ1cM0hvnIr8IowH7hFaeXJZ6cp4/edit#slide=id.g2309ce468a_22_0)
+
+*Sponsor / Advisor from TOC:* Solomon Hykes
+
+*Preferred maturity level:* incubating
+
+*Unique identifier:*
+
+* Notary: notary
+* The Update Framework: tuf
+
+*License:*
+
+* Notary: Apache 2.0 
+* TUF: Dual licensed under MIT and Apache 2.0
+
+*Source control repositories:*
+
+* https://github.com/docker/notary
+* https://github.com/theupdateframework/tuf
+* https://github.com/theupdateframework/taps 
+
+*Initial Committers:*
+
+* https://github.com/docker/notary/blob/master/MAINTAINERS
+* https://github.com/theupdateframework/tuf/blob/develop/AUTHORS.txt 
+
+*Infrastructure requirements (CI / CNCF Cluster):*
+
+* CircleCI
+* CodeCov
+* Travis CI
+
+*Issue tracker:*
+
+* https://github.com/docker/notary/issues
+* https://github.com/theupdateframework/tuf/issues
+
+*Mailing lists:*
+
+* Slack: https://dockercommunity.slack.com/messages/notary
+* Google Groups: https://groups.google.com/forum/#!forum/theupdateframework 
+
+*Website:*
+
+* TUF: https://theupdateframework.github.io/
+
+*Release methodology and mechanics:*
+
+* Feature based releases
+
+*Social media accounts:* None
+
+*Existing sponsorship:* Docker for Notary, National Science Foundation and NYU for TUF
+
+*Contributor statistics:*
+
+The notary community is growing slowly with a very small but active base and a larger group of occasional contributors. Maintainers are from Docker, CoreOS and Huawei.
+
+TUF maintainers from NYU and CoreOS.
+
+*Adopters:* Docker, Quay, Huawei, Motorola Solutions, VMWare
+
+*External Dependencies:*
+
+* https://github.com/docker/notary/blob/master/vendor.conf 
+* Protobuf
+* GRPC
+* MySQL/PostgreSQL/rethinkDB
+* https://github.com/yubico/yubico-piv-tool
+* https://github.com/flynn/gotuf (forked and heavily modified under the "tuf" directory in the notary repository)
+
+*Statement on alignment with CNCF mission:*
+
+Notary is the most secure and widely adopted implementation of The Update Framework to date, and represents a 
+critical security building block for ensuring the provenance and integrity of data in the field of 
+cloud-native computing. As an implementer of The Update Framework it can provide its guarantees over any 
+arbitrary digital content, making it ultimately flexible to any use case requiring security guarantees 
+against attacks up to and including nation state level.
+
+Additional Material
+---
+
+*Notary/TUF vs Traditional Package Signing*
+
+Traditional package signing methods commonly revolve around GPG signing of various metadata fragments. In a 
+sense, GPG is a primitive used by traditional package signing systems. If there was strong enough desire, 
+GPG could be integrated into any existing TUF implementation as an available signing option. TUF recognizes 
+that the existing signing systems have not gone far enough to address the threats that are meaningful in the 
+context of software distribution. It proposes a complete system for secure software distribution that 
+addresses these threats.
+
+Over the years many package management signing systems have been developed and they continue to make the 
+mistakes of the past because the community has largely focused on the expertise required to develop 
+crypto primitives, without also acknowledging the expertise required to design systems. To quote Duncan 
+Coutts in his explanation of Haskell’s choice to use TUF, “TUF has been designed by academic experts in 
+the subject, based both on research and existing real-world systems. Our crypto-humility should cover 
+not just crypto algorithms but extend to whole system designs.”
+
+*TUF vs GPG*
+
+GPG currently has much greater recognition that TUF. This is expected given the age and lack of 
+competition it has received. This does not automatically make it a good solution to signing requirements. 
+GPG lacks the same features as our “Traditional Package Managers”, as they have largely added very little 
+if anything meaningful on top of the GPG primitives.
+
+Nominally one could argue that GPG private key management is simpler than TUF private key management 
+purely on the basis that there are slightly fewer keys to manage. This marginal difference is a poor 
+tradeoff in the face of ease of integration. GPG is well recognized as being difficult to use [1] (response 
+at [5]), and even more difficult to integrate with at the library level as a developer [2]. By comparison, 
+one user was able to write a tool to use Notary to sign and verify git tags during a hackathon with no \
+help from the Notary maintainers [3].
+
+*Why a joint submission?*
+
+We want the TUF specification to be accepted into CNCF because it will make a clear statement of the 
+importance and expectations the community must have for the security of their software distribution 
+channels. Furthermore we want there to be implementations in many languages to enable broad adoption. 
+A joint submission of TUF and Notary is a highly cohesive package that lays a solid foundation for 
+package signing in CNCF, providing both the spec for guidance, and an implementation in Golang, which 
+is the majority language among existing CNCF projects.
+
+We are at an inflection point in the methods used to develop and deploy software. The paradigm shift 
+happening right now must be capitalized on lest we risk extending the the unacceptable status quo in 
+software distribution security.
+
+*Use Cases*
+
+The most unequivocal use case for TUF and Notary is securing software update systems. This is the stated 
+scope and primary goal of TUF. It is also a stated goal that the framework should be usable with both 
+new and existing software update systems.
+
+We should define what we mean by “software update system” in this context: a software update system is 
+a process and utilities that allow one to download and install entirely new software, and upgrades to 
+existing software, within a specific environment. Some examples are Python’s PIP, Debian’s APT, and 
+RedHat’s YUM systems.
+
+Container images map very closely to a typical software update system payload. Like some of those 
+mentioned, it uses TAR files containing the collection of files to be installed on the requesting host. 
+It uses a manifest, a JSON file, to describe how those files are used to set up and run the container. 
+The manifest is the root of a Merkle tree, containing the SHA256 checksums of the layers that make up 
+the image. This efficiently allows us to sign only the manifest using Notary and a user can perform a 
+verification of everything they download for the image.
+
+We also see a future for Notary and TUF in signing service or pod definitions. This strengthens 
+protections around what software can run on a cluster. We envision a single Notary repository 
+maintained within a cluster to which recognized delegates can push updates. This would be the only 
+mechanism for a cluster to receive updates to its definitions and automatically acts as a second 
+factor of authentication (something you have: the private key) in the presence of traditional 
+username+password based auth.
+
+Finally, we recognize that there is a natural link between code identity and container, service, and 
+pod identity. We believe that runtime identity ought to be tied to code signatures, so that policies 
+can be set such that only particular images may assume a runtime identity. For example, a customer 
+might specify that a particular signing process for container images is necessary in order to call 
+particular APIs within a cluster. This link between image identity and container runtime identity 
+requires a cryptographically strong, commonly shared image signing and verification system.
+
+Use cases that we consider in scope and that are already implemented or can be accomplished now:
+
+* Container image signing
+* General software package signing (a demo of this was put together using Notary to sign PIP packages for a talk at PyCon 2016 [4])
+* OS/Kernel signing (already in use in LinuxKit)
+* CI pipeline signing 
+    * Every entity performing a step in a CI pipeline (build, test, security scan, etc…) should add a signature and all signatures should be verified at deployment time.
+
+Use cases that are achievable with some additional work:
+
+* Signing cluster/service/pod definitions
+* Binding code signatures to service/container/pod identity
+
+Out of scope:
+
+* Signing communications, i.e. emails
+* Signed logs (though TUF/Notary could be applicable to signing log files backed up offsite)
+
+1. https://blog.filippo.io/giving-up-on-long-term-pgp/
+2. https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html
+3. https://github.com/docker/global-hack-day-3/tree/master/docker-bdx 
+4. https://www.youtube.com/watch?v=fDvO9jwXCV4
+5. https://arstechnica.co.uk/information-technology/2016/12/signal-does-not-replace-pgp/