From 4cf631f670d8e3ce3002d64a05a119a7afbe30bf Mon Sep 17 00:00:00 2001 From: David Lawrence Date: Fri, 19 Jun 2015 13:32:29 -0700 Subject: [PATCH] updating top level README --- README.md | 43 +++++++++++++++++-------------------------- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/README.md b/README.md index 220f22993a..a7b662d13b 100644 --- a/README.md +++ b/README.md @@ -1,34 +1,25 @@ +**N.B. The project is a work in progress and is not ready for production.** + # Notary ## Overview -Notary Server manages trust metadata as a complementary service to the registry. -It implements all endpoints under the `_trust` segment of the registry URLs. -Notary Server expects to manage TUF metadata and will do validation of one parent -level of content for any data uploaded to ensure repositories do not become -corrupted. This means either the keys in the root.json file will be used to -validate the uploaded role, or the keys in the immediate delegate parent will -be used. +The Notary project comprises server and client tools for running and interacting +with trusted collections. Please see the READMEs for the individual tools for +more information on their specifics. -Uploading a new root.json will be validated using the same token mechanism -present in the registry. A user having write permissions on a repository -will be sufficient to permit the uploading of a new root.json. +## Goals -## Timestamping +Notary aims to make the internet more secure by making it easy for people to +publish and verify content. We often rely on TLS to secure our communications +with a web server which is inherently flawed, as any compromise of the server +enables malicious content to be substituted for the legitimate content. -TUF requires a timestamp file be regularly generated. To achieve any ease -of use, it is necessary that Notary Server is responsible for generating the -timestamp.json based on the snapshot.json created and uploaded by the -repository owner. +With Notary, publishers can sign their content offline using keys kept highly +secure. Once the publisher is ready to make the content available, they can +push their signed trusted collection to a Notary Server. -It is bad policy to place any signing keys in frontline servers. While -Notary Server is capable of supporting this behaviour we recommend using a -separate service and server with highly restricted permissions. Rufus -is provided as a reference implementation of a remote signer. An -implementation that satisfies the gRPC interface defined in Rufus will -satisfy Notary Server's requirements. - -# Running - -`# docker-compose build` -`# docker-compose up` +Consumers, having acquired the publisher's public key through a secure channel, +can then communicate with any notary server or (insecure) mirror, relying +only on the publisher's key to determine the validity and integrity of the +received content.