docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove Notary docs 

Signed-off-by: Usha Mandya <usha.mandya@docker.com>
This commit is contained in:
Usha Mandya 2021-06-03 01:08:40 +01:00
parent da274abff6
commit 516d2fc839
21 changed files with 9 additions and 2469 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
_data/toc.yaml
View File

@ -1404,28 +1404,6 @@ manuals:
title: Release notes
- sectiontitle: Open-source projects
section:
- sectiontitle: Notary
section:
- path: /notary/getting_started/
title: Get started with Notary
- path: /notary/advanced_usage/
title: Use the Notary client
- path: /notary/service_architecture/
title: Understand the service architecture
- path: /notary/running_a_service/
title: Run a Notary service
- path: /notary/changelog/
title: Notary changelog
- sectiontitle: Configuration files
section:
- path: /notary/reference/server-config/
title: Server configuration
- path: /notary/reference/signer-config/
title: Signer configuration
- path: /notary/reference/client-config/
title: Client configuration
- path: /notary/reference/common-configs/
title: Common Server and signer configurations
- sectiontitle: Docker Registry
section:
- path: /registry/

9
engine/security/trust/index.md
View File

@ -4,6 +4,15 @@ keywords: content, trust, security, docker, documentation
title: Content trust in Docker
redirect_from:
- /engine/security/trust/content_trust/
- /notary/getting_started/
- /notary/advanced_usage/
- /notary/service_architecture/
- /notary/running_a_service/
- /notary/changelog/
- /notary/reference/server-config/
- /notary/reference/signer-config/
- /notary/reference/client-config/
- /notary/reference/common-configs/
---
When transferring data among networked systems, *trust* is a central concern. In

272
notary/advanced_usage.md
View File

@ -1,272 +0,0 @@
---
description: Becoming a power user of the notary client.
keywords: docker, notary, notary-client, docker content trust, content trust, power user, advanced
title: Use the Notary client for advanced users
---
This page explains advanced uses of Notary client for users who are running
their own Notary service. Make sure you have first read and understood how to
[run your own Notary service](running_a_service.md) before continuing.
## An important note about the examples
This document's command examples omit the `-s` and `-d` flags. If you do not
know what these options do, read the [Getting Started](getting_started.md) docs
or run `notary --help` before continuing. Once you understand what these flags do,
you must provide your own values for these options while following this document.
You can also configure these options, see [advanced configuration options](reference/index.md)
for more information.
## Initialize a Trusted Collection
Before adding and signing content to a collection, you must first initialize that collection.
```bash
$ notary init example.com/collection
No root keys found. Generating a new root key...
You are about to create a new root signing key passphrase. This passphrase
is used to protect the most sensitive key in your signing system.
Choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There is no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 1f54328:
Repeat passphrase for new root key with ID 1f54328:
Enter passphrase for new targets key with ID 1df39fc (example.com/collection):
Repeat passphrase for new targets key with ID 1df39fc (example.com/collection):
```
Initializing a trusted collection generates the following items; all keys use
asymmetric algorithms, but there is no requirement that they all use the _same_
algorithm:
- If no root key is found, an initial `root` key is generated. This key is
used as the default root of trust for all your trusted collections.
- A `targets` key and a `snapshot` key. The same password encrypts both of these
as the security profile of them (when both held by the author of the trusted
collection) is identical. This is why are not prompted for a snapshot key
password.
- A `timestamp` key. This is generated by the server on a request from the
client, returning just the public key. The server holds the private key and
signs timestamps on behalf of the user.
- Stub signed notary metadata. This stages the base version of the trust
metadata for the collection. It is finalized when it is published to the
server.
## Add and remove Targets
To add targets to a trusted collection with notary CLI:
```bash
$ notary add example.com/collection v1 my_file.txt
```
This adds the local file `my_file.txt` (which must exist relative to the
current working directory), under the target name `v1`, to the
`example.com/collection` collection we set up. The contents of the local file
are not actually added to the collection - a "target" consists of the file path
and one or more checksums of the contents.
This is an offline command, and we must run a
`notary publish example.com/collection` for the add to take effect.
To remove targets, we use the `notary remove` command, specifying the GUN and
target name.
```bash
$ notary remove example.com/collection v1
```
Removing a target is also an offline command that requires a
`notary publish example.com/collection` to take effect.
## Manage keys
By default, the notary client is responsible for managing the private keys for
root, targets, snapshot roles. All of these keys are generated by default when
initializing a new trusted collection. The keys are located in the notary `trust_dir`
directory. In addition, if delegation roles exist, those roles' keys are to also
managed by the notary client.
The notary server is always responsible for managing the timestamp key. However,
it is possible for the notary server to manage the snapshot key, if the snapshot
key is rotated from the notary client to server, as described in the following
subsection.
### Rotate keys
In case of potential compromise, notary provides a CLI command for rotating keys.
You can use the `notary key rotate` command to rotate the targets or snapshot
keys.
While the snapshot key is managed by the notary client by default, use the `notary key
rotate snapshot -r` command to rotate the snapshot key to the server, such that the
notary server can sign snapshots. This is particularly useful when using
delegations with a trusted collection, so that delegates never need access to the
snapshot key to push their updates to the collection.
New collections created by a Docker 1.11 Engine client cause the server
manage to the snapshot key by default. To reclaim control of the snapshot key on
the client, use the `notary key rotate` command without the `-r` flag.
The targets key must be locally managed - to rotate the targets key, for
instance in case of compromise, use the `notary key rotate targets` command
without the `-r` flag.
### Use a Yubikey
Notary can be used with
[Yubikey 4](https://www.yubico.com/products/yubikey-hardware/yubikey4/){: target="_blank" rel="noopener" class="_"}
keys, via a PKCS11 interface when the Yubikey has CCID mode enabled.
The Yubikey is prioritized to store root keys, and requires user
touch-input for signing. Yubikey support is included with the Docker Engine 1.11
client for use with Docker Content Trust.
Yubikey support requires
[Yubico PIV libraries](https://www.yubico.com/support/knowledge-base/categories/downloads/){: target="_blank" rel="noopener" class="_"}
(bundled with the PIV tools) to be available in standard library locations.
## Work with delegation roles
Delegation roles simplify collaborator workflows in notary trusted collections, and
also allow for fine-grained permissions within a collection's contents across
delegations. In essence, delegation roles are restricted versions of the targets
role that are only allowed to sign targets within certain filepaths.
A delegation role is given its own keys, such that each collaborator can keep
his own private key without the administrator having to share the
targets key or allow a collaborator write access to all targets of the
collection.
Before adding any delegations, you should rotate the snapshot key to the server.
This is done by default for new collections created with a Docker Engine 1.11 client.
Delegation roles do not require the snapshot key to publish
their own targets to the collection, since the server can publish the valid
snapshot with the delegation targets:
```bash
$ notary key rotate example.com/collection snapshot -r
```
Here, `-r` specifies to rotate the key to the remote server.
When adding a delegation, your must acquire a x509 certificate with the public
key of the user you wish to delegate to. The user who assumes this
delegation role must hold the private key to sign content with notary.
Once you've acquired the delegate's x509 certificate, you can add a delegation
for this user:
```bash
$ notary delegation add example.com/collection targets/releases cert.pem --paths="delegation/path"
```
The preceding example illustrates a request to add the delegation
`targets/releases` to the GUN `example.com/collection`. The delegation name must
be prefixed by `targets/` to be valid, since all delegations are restricted
versions of the target role. The command adds the public key contained in the
x509 cert `cert.pem` to the `targets/releases` delegation.
For the `targets/releases` delegation role to sign content, the delegation user
must possess the private key corresponding to this public key. This command
restricts this delegation to only publish content under pathnames prefixed by
`delegation/path`. With the given path of "delegation/path", the `targets/releases`
role could sign paths like "delegation/path/content.txt", "delegation/path_file.txt"
and "delegation/path.txt". You can add more paths in a comma-separated list under
`--paths`, or pass the `--all-paths` flag to allow this delegation to publish
content under any pathname.
After publishing, you can view delegations using a list command:
```bash
$ notary delegation list example.com/collection
ROLE PATHS KEY IDS THRESHOLD
---------------------------------------------------------------------------------------------------------------
targets/releases delegation/path 729c7094a8210fd1e780e7b17b7bb55c9a28a48b871b07f65d97baf93898523a 1
```
You can see the `targets/releases` with its paths and key IDs. If you wish to modify these fields, you can do so with additional `notary delegation add` or `notary delegation remove` commands on this role.
A threshold of `1` indicates that only one of the keys specified in `KEY IDS` is required to publish to this delegation. Thresholds other than 1 are not currently supported. To remove a delegation role entirely, or just individual keys and/or paths, use the `notary delegation remove` command:
```bash
$ notary delegation remove example.com/user targets/releases
Are you sure you want to remove all data for this delegation? (yes/no)
yes
Forced removal (including all keys and paths) of delegation role targets/releases to repository "example.com/user" staged for next publish.
```
You can remove individual keys and/or paths by passing keys as arguments, and/or
paths under the `--paths` flag. Use `--all-paths` to clear all paths for this
role. If you specify all key IDs currently in the delegation role, you
delete the role entirely.
To add targets to a specified delegation role, we can use the `notary add`
command with the `--roles` flag.
You must have imported an appropriate delegation key for this role. To do so,
you can run `notary key import <KEY_FILE> --role user` with the private key PEM
file, or drop the private key PEM in `private/tuf_keys` as `<KEY_ID>.key` with
the `role` PEM header set to `user`.
```bash
$ notary add example/collections delegation/path/target delegation_file.txt --roles=targets/releases
```
In the preceding example, you add the target `delegation/path/target` to
collection `example/collections` staged for next publish. The file
`delegation_file.txt` is a target `delegation/path/target` using the delegation
role `targets/releases`. This target's path is valid because it is prefixed by
the delegation role's valid path.
The `notary list` and `notary remove` commands can also take the `--roles` flag
to specify roles to list or remove targets from. By default, this operates over
the base `targets` role.
To remove this target from our delegation, use the `notary remove` command with
the same flag:
```bash
$ notary remove example/collections delegation/path/target --roles=targets/releases
```
## Use delegations with content trust
Docker Engine 1.10 and above supports the usage of the `targets/releases`
delegation as the canonical source of a trusted image tag, if it exists.
When running `docker pull` with Docker Content Trust on Docker Engine 1.10,
Docker attempts to search the `targets/releases` role for the signed image tag,
and falls back to the default `targets` role if it does not exist. When
searching the default `targets` role, Docker 1.10 may pick up on other
non-`targets/releases` delegation roles' signed images if they exist for this tag.
In Docker 1.11, this behavior is changed such that all `docker pull` commands with
Docker Content Trust must pull tags only signed by the `targets/releases` delegation role
or the `targets` base role.
When running `docker push` with Docker Content Trust, Docker Engine 1.10
attempts to sign and push with the `targets/releases` delegation role if it exists,
otherwise falling back to the `targets` role. In Docker 1.11, a `docker push`
attempts to sign and push with all delegation roles directly under targets
(ex: `targets/role` but not `targets/nested/role`) that the user has signing keys for.
If delegation roles exist but the user does not have signing keys, the push fails.
If no delegation roles exist, the push attempts to sign with the base `targets` role.
To use the `targets/releases` role for pushing and pulling images with content trust,
follow the steps above to add and publish the delegation role with notary.
When adding the delegation, the `--all-paths` flag should be used to allow signing all tags.
## Files and state on disk
Notary stores state in its `trust_dir` directory, which is `~/.notary` by
default or usually `~/.docker/trust` when enabling docker content trust. Within this
directory, `trusted_certificates` stores certificates for bootstrapping trust in
a collection, `tuf` stores TUF metadata and changelists to be applied to a GUN,
and `private` stores private keys.
The `root_keys` subdirectory within `private` stores root private keys, while
`tuf_keys` stores targets, snapshots, and delegations private keys.

38
notary/changelog.md
View File

@ -1,38 +0,0 @@
---
description: Notary release changelog
keywords: docker, notary, changelog, notary changelog, notary releases, releases, notary versions, versions
title: Notary Changelog
---
## v0.3
#### 5/11/2016
Implements root key and certificate rotation, as well as trust pinning configurations to specify known good key IDs and CAs to replace TOFU.
Additional improvements and fixes to notary internals, and RethinkDB support.
> Detailed release notes can be found here:
<a href="https://github.com/docker/notary/releases/tag/v0.3.0" target="_blank">v0.3 release notes</a>.
## v0.2
#### 2/24/2016
Adds support for
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L387" target="_blank">delegation
roles</a> in TUF.
Delegations allow for easier key management amongst collaborators in a notary trusted collection, and fine-grained permissions on what content each delegate is allowed to modify and sign.
This version also supports managing the snapshot key on notary server, which should be used when enabling delegations on a trusted collection.
Moreover, this version also adds more key management functionality to the notary CLI, and changes the docker-compose development configuration to use the official MariaDB image.
> Detailed release notes can be found here:
<a href="https://github.com/docker/notary/releases/tag/v0.2.0" target="_blank">v0.2 release notes</a>.
## v0.1
#### 11/15/2015
Initial notary non-alpha release.
Implements The Update Framework (TUF) with root, targets, snapshot, and timestamp roles to sign and verify content of a trusted collection.
> Detailed release notes can be found here:
<a href="https://github.com/docker/notary/releases/tag/v0.1" target="_blank">v0.1 release notes</a>.

148
notary/getting_started.md
View File

@ -1,148 +0,0 @@
---
description: Performing basic operation to use Notary in tandem with Docker Content Trust.
keywords: docker, Notary, notary-client, docker content trust, content trust
title: Get started with Notary
---
This document describes basic use of the Notary CLI as a tool supporting Docker
Content Trust. For more advanced use cases, you must
[run your own Notary service](running_a_service.md). Read the
[use the Notary client for advanced users](advanced_usage.md) documentation.
## What is Notary
Notary is a tool for publishing and managing trusted collections of content.
Publishers can digitally sign collections and consumers can verify integrity
and origin of content. This ability is built on a straightforward key management
and signing interface to create signed collections and configure trusted publishers.
With Notary anyone can provide trust over arbitrary collections of data. Using
[The Update Framework (TUF)](https://www.theupdateframework.com/)
as the underlying security framework, Notary takes care of the operations necessary
to create, manage, and distribute the metadata necessary to ensure the integrity and
freshness of your content.
## Install Notary
You can download precompiled notary binary for 64 bit Linux or macOS from the
Notary repository's
[Releases page on Github](https://github.com/docker/notary/releases).
## Understand Notary naming
Notary uses Globally Unique Names (GUNs) to identify trust collections. To
enable Notary to run in a multi-tenant fashion, you must use this format
when interacting with Docker Hub through the Notary client. When specifying
Docker image names for the Notary client, the GUN format is:
- For official images (identifiable by the "Official Image" moniker), the
image name as displayed on Docker Hub, prefixed with `docker.io/library/`. For
example, if you would normally type `docker pull ubuntu` you must enter `notary
{cmd} docker.io/library/ubuntu`.
- For all other images, the image name as displayed on Docker Hub, prefixed by `docker.io`.
The Docker Engine client takes care of these name expansions for you so do not
change the names you use with the Engine client or API. This is a requirement
only when interacting with the same Docker Hub repositories through the Notary
client.
## Inspect a Docker Hub repository
The most basic operation is listing the available signed tags in a repository.
The Notary client used in isolation does not know where the trust repositories
are located. So, you must provide the `-s` (or long form `--server`) flag to
tell the client which repository server it should communicate with.
The official Docker Hub Notary servers are located at
`https://notary.docker.io`. If you would like to use your own Notary server,
it is important to use the same or a newer
[Notary version](https://github.com/docker/notary/releases),
as the client for feature compatibility (ex: client version 0.2, server/signer version >= 0.2).
Additionally, Notary stores your own signing keys,
and a cache of previously downloaded trust metadata in a directory, provided
with the `-d` flag. When interacting with Docker Hub repositories, you must
instruct the client to use the associated trust directory, which by default is
found at `.docker/trust` within the calling user's home directory (failing to
use this directory may result in errors when publishing updates to your trust
data):
```bash
$ notary -s https://notary.docker.io -d ~/.docker/trust list docker.io/library/alpine
NAME DIGEST SIZE (BYTES) ROLE
------------------------------------------------------------------------------------------------------
2.6 e9cec9aec697d8b9d450edd32860ecd363f2f3174c8338beb5f809422d182c63 1374 targets
2.7 9f08005dff552038f0ad2f46b8e65ff3d25641747d3912e3ea8da6785046561a 1374 targets
3.1 e876b57b2444813cd474523b9c74aacacc238230b288a22bccece9caf2862197 1374 targets
3.2 4a8c62881c6237b4c1434125661cddf09434d37c6ef26bf26bfaef0b8c5e2f05 1374 targets
3.3 2d4f890b7eddb390285e3afea9be98a078c2acd2fb311da8c9048e3d1e4864d3 1374 targets
edge 878c1b1d668830f01c2b1622ebf1656e32ce830850775d26a387b2f11f541239 1374 targets
latest 24a36bbc059b1345b7e8be0df20f1b23caa3602e85d42fff7ecd9d0bd255de56 1377 targets
```
The output shows us the names of the tags available, the hex encoded sha256
digest of the image manifest associated with that tag, the size of the manifest,
and the Notary role that signed this tag into the repository. The "targets" role
is the most common role in a simple repository. When a repository has (or
expects) to have collaborators, you may see other "delegated" roles listed as
signers, based on the choice of the administrator as to how they organize their
collaborators.
When you run a `docker pull` command, Docker Engine is using an integrated
Notary library (the same one as Notary CLI) to request the mapping of tag
to sha256 digest for the one tag you are interested in (or if you passed the
`--all` flag, the client uses the list operation to efficiently retrieve all
the mappings). Having validated the signatures on the trust data, the client
instructs the Engine to do a "pull by digest". During this pull, the
Engine uses the sha256 checksum as a content address to request and validate the
image manifest from the Docker registry.
## Delete a tag
Notary generates and stores signing keys on the host it's running on. This means
that the Docker Hub cannot delete tags from the trust data, they must be deleted
using the Notary client. You can do this with the `notary remove` command.
Again, you must direct it to speak to the correct Notary server. Neither
you nor the author has permissions to delete tags from the official `alpine`
repository, so the output below is for demonstration only:
```bash
$ notary -s https://notary.docker.io -d ~/.docker/trust remove docker.io/library/alpine 2.6
Removal of 2.6 from docker.io/library/alpine staged for next publish.
```
In the preceding example, the output message indicates that only the removal was
staged. When performing any write operations they are staged into a change list.
This list is applied to the latest version of the trust repository the next time
a `notary publish` is run for that repository.
You can see a pending change by running `notary status` for the modified
repository. The `status` subcommand is an offline operation and as such, does
not require the `-s` flag, however it silently ignores the flag if provided.
Failing to provide the correct value for the `-d` flag may show the wrong
(probably empty) change list:
```bash
$ notary -d ~/.docker/trust status docker.io/library/alpine
Unpublished changes for docker.io/library/alpine:
action scope type path
----------------------------------------------------
delete targets target 2.6
$ notary -s https://notary.docker.io publish docker.io/library/alpine
```
## Configure the client
It is verbose and tedious to always provide the `-s` and `-d` flags
manually to most commands. A simple way to create preconfigured versions of the
Notary command is via aliases. Add the following to your `.bashrc` or
equivalent:
```bash
alias dockernotary="notary -s https://notary.docker.io -d ~/.docker/trust"
```
More advanced methods of configuration, and additional options, can be found in
the [configuration doc](reference/index.md) and by running `notary --help`.

173
notary/images/key-hierarchy.svg
View File

@ -1,173 +0,0 @@
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 460 410" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.41421;">
<g transform="matrix(1,0,0,1,-174.938,-212.9)">
<g transform="matrix(1,0,0,1,411.87,472.914)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Delegation2</text>
</g>
</g>
<g transform="matrix(1,0,0,1,298.419,472.914)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Delegation1</text>
</g>
</g>
<path d="M345.466,282.138L345.466,306.444L234,306.444L234,320.85" style="fill:none;stroke-width:1px;stroke:black;"/>
<path d="M345.466,282.138L345.466,320.85" style="fill:none;stroke-width:1px;stroke:black;"/>
<path d="M345.466,282.138L345.466,306.444L456.931,306.444L456.931,320.85" style="fill:none;stroke-width:1px;stroke:black;"/>
<g transform="matrix(1,0,0,1,324.878,248.776)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Root</text>
</g>
</g>
<g transform="matrix(1,0,0,1,194.128,375.664)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Timestamp</text>
</g>
</g>
<g transform="matrix(1,0,0,1,311.234,375.664)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Snapshot</text>
</g>
</g>
<path d="M453.938,384.888L453.938,408.262L398.262,408.262L341.091,408.262L341.091,421.475" style="fill:none;stroke-width:1px;stroke:black;"/>
<path d="M453.938,384.888L453.938,408.344L567.994,408.344L567.994,421.475" style="fill:none;stroke-width:1px;stroke:black;"/>
<g transform="matrix(1,0,0,1,427.938,360.664)">
<g transform="matrix(1,0,0,1,0.152,15)">
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">T</text>
</g>
<g transform="matrix(1,0,0,1,7.56,15)">
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">ar</text>
</g>
<g transform="matrix(1,0,0,1,21.032,15)">
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">gets</text>
</g>
</g>
<g transform="matrix(1,0,0,1,525.322,472.914)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Delegation3</text>
</g>
</g>
<path d="M454.542,482.138L454.542,509.063L512.48,509.063L512.48,523.85" style="fill:none;stroke-width:1px;stroke:black;"/>
<path d="M454.542,482.138L454.542,508.895L424.75,508.895L396.605,508.895L396.605,523.85" style="fill:none;stroke-width:1px;stroke:black;"/>
<g transform="matrix(1,0,0,1,353.933,578.664)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Delegation4</text>
</g>
</g>
<g transform="matrix(1,0,0,1,469.808,578.664)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:16px;fill:black;">Delegation5</text>
</g>
</g>
<path d="M453.938,386.789L453.938,398.689L454.24,421.066L454.245,421.476" style="fill:none;stroke-width:1px;stroke:black;"/>
<path d="M534.008,544.854L534.008,547.467L532.231,550.77L532.231,548.154L534.008,544.854Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M533.008,547.391L532.231,550.77L511.864,551.052L511.445,548.266L533.008,547.391Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M511.861,548.447L511.861,551.06C511.815,551.207 511.231,552.354 510.883,552.984L510.633,549.766C510.981,549.134 511.815,548.593 511.861,548.447Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M511.864,548.438L511.864,551.052L511.861,551.06L511.861,548.447L511.864,548.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M511.864,548.438L511.864,551.052C511.82,551.189 511.606,551.685 511.24,552.343L511.24,549.73C511.606,549.07 511.82,548.576 511.864,548.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M511.633,548.953L511.289,552.218C511.014,552.718 510.365,553.725 509.977,554.171L510.008,551.453C510.397,551.002 511.42,549.391 511.633,548.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M511.445,549.328L511.24,552.343C510.94,552.927 510.504,553.537 510.055,554.046L510.125,551.391C510.574,550.879 511.144,549.908 511.445,549.328Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M510.336,551.031L510.195,553.891C509.787,554.402 509.228,555.013 508.661,555.459L508.133,552.641C508.702,552.199 509.928,551.559 510.336,551.031Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M510.211,551.046L510.125,554.004C509.717,554.516 509.186,555.039 508.618,555.484L508.336,552.843C508.904,552.402 509.803,551.559 510.211,551.046Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M509.133,552.016C507.123,553.65 504.227,555.275 501.811,555.275C499.066,555.275 496.342,554.244 494.268,552.25C493.971,551.971 493.684,551.66 493.412,551.336C491.758,549.328 490.952,546.914 490.952,544.513L490.952,547.127C490.952,549.527 491.758,551.945 493.412,553.949C493.684,554.275 493.971,554.582 494.268,554.865C496.342,556.861 499.066,557.888 501.811,557.888C504.227,557.888 506.651,557.092 508.661,555.459L509.133,552.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M490.952,547.127L490.952,544.513C490.952,546.914 491.758,549.328 493.412,551.336C493.684,551.66 493.971,551.971 494.268,552.25C496.342,554.244 499.066,555.275 501.811,555.275C504.227,555.275 506.651,554.476 508.661,552.842L508.661,555.459C506.651,557.092 504.227,557.888 501.811,557.888C499.066,557.888 496.342,556.861 494.268,554.865C493.971,554.582 493.684,554.275 493.412,553.949C491.758,551.945 490.952,549.527 490.952,547.127Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M497.037,547.171C498.614,547.158 499.864,545.863 499.846,544.314C499.82,542.759 498.545,541.521 496.981,541.521C496.973,541.521 496.965,541.521 496.955,541.525C495.397,541.55 494.131,542.83 494.161,544.394C494.172,545.927 495.434,547.171 496.989,547.171C497.004,547.171 497.022,547.171 497.037,547.171M530.082,541.189L534.008,544.854L532.231,548.154L511.864,548.438C511.82,548.576 511.606,549.07 511.24,549.73C510.94,550.31 510.574,550.879 510.125,551.391C509.717,551.902 509.228,552.4 508.661,552.842C506.651,554.476 504.227,555.275 501.811,555.275C499.066,555.275 496.342,554.244 494.268,552.25C493.971,551.971 493.684,551.66 493.412,551.336C489.611,546.726 490.291,539.947 494.934,536.188C496.945,534.546 499.375,533.75 501.793,533.75C504.221,533.75 506.633,534.552 508.594,536.123C510.073,537.211 511.028,538.785 511.077,538.871L512.215,538.924L517.186,538.855L518.936,541.904L523.147,541.509L524.762,543.168L526.24,543.49L530.082,541.189" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M418.133,544.854L418.133,547.467L416.356,550.77L416.356,548.154L418.133,544.854Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M417.133,547.391L416.356,550.77L395.989,551.052L395.57,548.266L417.133,547.391Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M395.986,548.447L395.986,551.06C395.94,551.207 395.356,552.354 395.008,552.984L394.758,549.766C395.106,549.134 395.94,548.593 395.986,548.447Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M395.989,548.438L395.989,551.052L395.986,551.06L395.986,548.447L395.989,548.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M395.989,548.438L395.989,551.052C395.945,551.189 395.731,551.685 395.365,552.343L395.365,549.73C395.731,549.07 395.945,548.576 395.989,548.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M395.758,548.953L395.414,552.218C395.139,552.718 394.49,553.725 394.102,554.171L394.133,551.453C394.522,551.002 395.545,549.391 395.758,548.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M395.57,549.328L395.365,552.343C395.065,552.927 394.629,553.537 394.18,554.046L394.25,551.391C394.699,550.879 395.269,549.908 395.57,549.328Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M394.461,551.031L394.32,553.891C393.912,554.402 393.353,555.013 392.786,555.459L392.258,552.641C392.827,552.199 394.053,551.559 394.461,551.031Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M394.336,551.046L394.25,554.004C393.842,554.516 393.311,555.039 392.743,555.484L392.461,552.843C393.029,552.402 393.928,551.559 394.336,551.046Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M393.258,552.016C391.248,553.65 388.352,555.275 385.936,555.275C383.191,555.275 380.467,554.244 378.393,552.25C378.096,551.971 377.809,551.66 377.537,551.336C375.883,549.328 375.077,546.914 375.077,544.513L375.077,547.127C375.077,549.527 375.883,551.945 377.537,553.949C377.809,554.275 378.096,554.582 378.393,554.865C380.467,556.861 383.191,557.888 385.936,557.888C388.352,557.888 390.776,557.092 392.786,555.459L393.258,552.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M375.077,547.127L375.077,544.513C375.077,546.914 375.883,549.328 377.537,551.336C377.809,551.66 378.096,551.971 378.393,552.25C380.467,554.244 383.191,555.275 385.936,555.275C388.352,555.275 390.776,554.476 392.786,552.842L392.786,555.459C390.776,557.092 388.352,557.888 385.936,557.888C383.191,557.888 380.467,556.861 378.393,554.865C378.096,554.582 377.809,554.275 377.537,553.949C375.883,551.945 375.077,549.527 375.077,547.127Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M381.162,547.171C382.739,547.158 383.989,545.863 383.971,544.314C383.945,542.759 382.67,541.521 381.106,541.521C381.098,541.521 381.09,541.521 381.08,541.525C379.522,541.55 378.256,542.83 378.286,544.394C378.297,545.927 379.559,547.171 381.114,547.171C381.129,547.171 381.147,547.171 381.162,547.171M414.207,541.189L418.133,544.854L416.356,548.154L395.989,548.438C395.945,548.576 395.731,549.07 395.365,549.73C395.065,550.31 394.699,550.879 394.25,551.391C393.842,551.902 393.353,552.4 392.786,552.842C390.776,554.476 388.352,555.275 385.936,555.275C383.191,555.275 380.467,554.244 378.393,552.25C378.096,551.971 377.809,551.66 377.537,551.336C373.736,546.726 374.416,539.947 379.059,536.188C381.07,534.546 383.5,533.75 385.918,533.75C388.346,533.75 390.758,534.552 392.719,536.123C394.198,537.211 395.153,538.785 395.202,538.871L396.34,538.924L401.311,538.855L403.061,541.904L407.272,541.509L408.887,543.168L410.365,543.49L414.207,541.189" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M589.522,442.479L589.522,445.092L587.745,448.395L587.745,445.779L589.522,442.479Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M588.522,445.016L587.745,448.395L567.378,448.677L566.959,445.891L588.522,445.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M567.375,446.072L567.375,448.685C567.329,448.832 566.745,449.979 566.397,450.609L566.147,447.391C566.495,446.759 567.329,446.218 567.375,446.072Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M567.378,446.063L567.378,448.677L567.375,448.685L567.375,446.072L567.378,446.063Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M567.378,446.063L567.378,448.677C567.334,448.814 567.12,449.31 566.754,449.968L566.754,447.355C567.12,446.695 567.334,446.201 567.378,446.063Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M567.147,446.578L566.804,449.843C566.528,450.343 565.879,451.35 565.491,451.796L565.522,449.078C565.911,448.627 566.934,447.016 567.147,446.578Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M566.959,446.953L566.754,449.968C566.454,450.552 566.018,451.162 565.569,451.671L565.639,449.016C566.088,448.504 566.659,447.533 566.959,446.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M565.85,448.656L565.709,451.516C565.301,452.027 564.743,452.638 564.175,453.084L563.647,450.266C564.216,449.824 565.442,449.184 565.85,448.656Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M565.725,448.671L565.639,451.629C565.231,452.141 564.7,452.664 564.132,453.109L563.85,450.468C564.418,450.027 565.317,449.184 565.725,448.671Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M564.647,449.641C562.638,451.275 559.741,452.9 557.325,452.9C554.58,452.9 551.856,451.869 549.782,449.875C549.485,449.596 549.198,449.285 548.926,448.961C547.272,446.953 546.466,444.539 546.466,442.138L546.466,444.752C546.466,447.152 547.272,449.57 548.926,451.574C549.198,451.9 549.485,452.207 549.782,452.49C551.856,454.486 554.58,455.513 557.325,455.513C559.741,455.513 562.165,454.717 564.175,453.084L564.647,449.641Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M546.466,444.752L546.466,442.138C546.466,444.539 547.272,446.953 548.926,448.961C549.198,449.285 549.485,449.596 549.782,449.875C551.856,451.869 554.58,452.9 557.325,452.9C559.741,452.9 562.165,452.101 564.175,450.467L564.175,453.084C562.165,454.717 559.741,455.513 557.325,455.513C554.58,455.513 551.856,454.486 549.782,452.49C549.485,452.207 549.198,451.9 548.926,451.574C547.272,449.57 546.466,447.152 546.466,444.752Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M552.551,444.796C554.128,444.783 555.378,443.488 555.36,441.939C555.334,440.384 554.059,439.146 552.495,439.146C552.487,439.146 552.479,439.146 552.47,439.15C550.911,439.175 549.645,440.455 549.675,442.019C549.686,443.552 550.948,444.796 552.503,444.796C552.518,444.796 552.536,444.796 552.551,444.796M585.596,438.814L589.522,442.479L587.745,445.779L567.378,446.063C567.334,446.201 567.12,446.695 566.754,447.355C566.454,447.935 566.088,448.504 565.639,449.016C565.231,449.527 564.743,450.025 564.175,450.467C562.165,452.101 559.741,452.9 557.325,452.9C554.58,452.9 551.856,451.869 549.782,449.875C549.485,449.596 549.198,449.285 548.926,448.961C545.125,444.351 545.805,437.572 550.448,433.813C552.459,432.171 554.889,431.375 557.307,431.375C559.735,431.375 562.147,432.177 564.108,433.748C565.587,434.836 566.542,436.41 566.591,436.496L567.729,436.549L572.7,436.48L574.45,439.529L578.661,439.134L580.276,440.793L581.754,441.115L585.596,438.814" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M476.07,442.479L476.07,445.092L474.293,448.395L474.293,445.779L476.07,442.479Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M475.07,445.016L474.293,448.395L453.926,448.677L453.508,445.891L475.07,445.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M453.924,446.072L453.924,448.685C453.877,448.832 453.293,449.979 452.945,450.609L452.695,447.391C453.043,446.759 453.877,446.218 453.924,446.072Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M453.926,446.063L453.926,448.677L453.924,448.685L453.924,446.072L453.926,446.063Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M453.926,446.063L453.926,448.677C453.883,448.814 453.668,449.31 453.303,449.968L453.303,447.355C453.668,446.695 453.883,446.201 453.926,446.063Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M453.695,446.578L453.352,449.843C453.077,450.343 452.428,451.35 452.039,451.796L452.07,449.078C452.459,448.627 453.482,447.016 453.695,446.578Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M453.508,446.953L453.303,449.968C453.002,450.552 452.566,451.162 452.118,451.671L452.187,449.016C452.637,448.504 453.207,447.533 453.508,446.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M452.398,448.656L452.258,451.516C451.85,452.027 451.291,452.638 450.723,453.084L450.195,450.266C450.764,449.824 451.99,449.184 452.398,448.656Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M452.273,448.671L452.187,451.629C451.779,452.141 451.248,452.664 450.68,453.109L450.398,450.468C450.967,450.027 451.865,449.184 452.273,448.671Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M451.195,449.641C449.186,451.275 446.289,452.9 443.873,452.9C441.129,452.9 438.404,451.869 436.33,449.875C436.033,449.596 435.746,449.285 435.475,448.961C433.82,446.953 433.014,444.539 433.014,442.138L433.014,444.752C433.014,447.152 433.82,449.57 435.475,451.574C435.746,451.9 436.033,452.207 436.33,452.49C438.404,454.486 441.129,455.513 443.873,455.513C446.289,455.513 448.713,454.717 450.723,453.084L451.195,449.641Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M433.014,444.752L433.014,442.138C433.014,444.539 433.82,446.953 435.475,448.961C435.746,449.285 436.033,449.596 436.33,449.875C438.404,451.869 441.129,452.9 443.873,452.9C446.289,452.9 448.713,452.101 450.723,450.467L450.723,453.084C448.713,454.717 446.289,455.513 443.873,455.513C441.129,455.513 438.404,454.486 436.33,452.49C436.033,452.207 435.746,451.9 435.475,451.574C433.82,449.57 433.014,447.152 433.014,444.752Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M439.1,444.796C440.676,444.783 441.926,443.488 441.908,441.939C441.883,440.384 440.607,439.146 439.043,439.146C439.036,439.146 439.028,439.146 439.018,439.15C437.459,439.175 436.194,440.455 436.223,442.019C436.235,443.552 437.496,444.796 439.051,444.796C439.066,444.796 439.084,444.796 439.1,444.796M472.144,438.814L476.07,442.479L474.293,445.779L453.926,446.063C453.883,446.201 453.668,446.695 453.303,447.355C453.002,447.935 452.637,448.504 452.187,449.016C451.779,449.527 451.291,450.025 450.723,450.467C448.713,452.101 446.289,452.9 443.873,452.9C441.129,452.9 438.404,451.869 436.33,449.875C436.033,449.596 435.746,449.285 435.475,448.961C431.674,444.351 432.353,437.572 436.996,433.813C439.008,432.171 441.437,431.375 443.856,431.375C446.283,431.375 448.695,432.177 450.657,433.748C452.135,434.836 453.09,436.41 453.139,436.496L454.278,436.549L459.248,436.48L460.998,439.529L465.209,439.134L466.824,440.793L468.303,441.115L472.144,438.814" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M362.619,442.479L362.619,445.092L360.842,448.395L360.842,445.779L362.619,442.479Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M361.619,445.016L360.842,448.395L340.475,448.677L340.056,445.891L361.619,445.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M340.472,446.072L340.472,448.685C340.426,448.832 339.842,449.979 339.494,450.609L339.244,447.391C339.592,446.759 340.426,446.218 340.472,446.072Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M340.475,446.063L340.475,448.677L340.472,448.685L340.472,446.072L340.475,446.063Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M340.475,446.063L340.475,448.677C340.431,448.814 340.217,449.31 339.851,449.968L339.851,447.355C340.217,446.695 340.431,446.201 340.475,446.063Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M340.244,446.578L339.9,449.843C339.625,450.343 338.976,451.35 338.588,451.796L338.619,449.078C339.008,448.627 340.031,447.016 340.244,446.578Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M340.056,446.953L339.851,449.968C339.551,450.552 339.115,451.162 338.666,451.671L338.736,449.016C339.185,448.504 339.755,447.533 340.056,446.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M338.947,448.656L338.806,451.516C338.398,452.027 337.839,452.638 337.272,453.084L336.744,450.266C337.313,449.824 338.539,449.184 338.947,448.656Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M338.822,448.671L338.736,451.629C338.328,452.141 337.797,452.664 337.229,453.109L336.947,450.468C337.515,450.027 338.414,449.184 338.822,448.671Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M337.744,449.641C335.734,451.275 332.838,452.9 330.422,452.9C327.677,452.9 324.953,451.869 322.879,449.875C322.582,449.596 322.295,449.285 322.023,448.961C320.369,446.953 319.563,444.539 319.563,442.138L319.563,444.752C319.563,447.152 320.369,449.57 322.023,451.574C322.295,451.9 322.582,452.207 322.879,452.49C324.953,454.486 327.677,455.513 330.422,455.513C332.838,455.513 335.262,454.717 337.272,453.084L337.744,449.641Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M319.563,444.752L319.563,442.138C319.563,444.539 320.369,446.953 322.023,448.961C322.295,449.285 322.582,449.596 322.879,449.875C324.953,451.869 327.677,452.9 330.422,452.9C332.838,452.9 335.262,452.101 337.272,450.467L337.272,453.084C335.262,454.717 332.838,455.513 330.422,455.513C327.677,455.513 324.953,454.486 322.879,452.49C322.582,452.207 322.295,451.9 322.023,451.574C320.369,449.57 319.563,447.152 319.563,444.752Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M325.648,444.796C327.225,444.783 328.475,443.488 328.457,441.939C328.431,440.384 327.156,439.146 325.592,439.146C325.584,439.146 325.576,439.146 325.566,439.15C324.008,439.175 322.742,440.455 322.772,442.019C322.783,443.552 324.045,444.796 325.6,444.796C325.615,444.796 325.633,444.796 325.648,444.796M358.693,438.814L362.619,442.479L360.842,445.779L340.475,446.063C340.431,446.201 340.217,446.695 339.851,447.355C339.551,447.935 339.185,448.504 338.736,449.016C338.328,449.527 337.839,450.025 337.272,450.467C335.262,452.101 332.838,452.9 330.422,452.9C327.677,452.9 324.953,451.869 322.879,449.875C322.582,449.596 322.295,449.285 322.023,448.961C318.222,444.351 318.902,437.572 323.545,433.813C325.556,432.171 327.986,431.375 330.404,431.375C332.832,431.375 335.244,432.177 337.205,433.748C338.684,434.836 339.639,436.41 339.688,436.496L340.826,436.549L345.797,436.48L347.547,439.529L351.758,439.134L353.373,440.793L354.851,441.115L358.693,438.814" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M366.994,269.104L366.994,271.717L365.217,275.02L365.217,272.404L366.994,269.104Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M365.994,271.641L365.217,275.02L344.85,275.302L344.431,272.516L365.994,271.641Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.847,272.697L344.847,275.31C344.801,275.457 344.217,276.604 343.869,277.234L343.619,274.016C343.967,273.384 344.801,272.843 344.847,272.697Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.85,272.688L344.85,275.302L344.847,275.31L344.847,272.697L344.85,272.688Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.85,272.688L344.85,275.302C344.806,275.439 344.592,275.935 344.226,276.593L344.226,273.98C344.592,273.32 344.806,272.826 344.85,272.688Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.619,273.203L344.275,276.468C344,276.968 343.351,277.975 342.963,278.421L342.994,275.703C343.383,275.252 344.406,273.641 344.619,273.203Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.431,273.578L344.226,276.593C343.926,277.177 343.49,277.787 343.041,278.296L343.111,275.641C343.56,275.129 344.13,274.158 344.431,273.578Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M343.322,275.281L343.181,278.141C342.773,278.652 342.214,279.263 341.647,279.709L341.119,276.891C341.688,276.449 342.914,275.809 343.322,275.281Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M343.197,275.296L343.111,278.254C342.703,278.766 342.172,279.289 341.604,279.734L341.322,277.093C341.89,276.652 342.789,275.809 343.197,275.296Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M342.119,276.266C340.109,277.9 337.213,279.525 334.797,279.525C332.052,279.525 329.328,278.494 327.254,276.5C326.957,276.221 326.67,275.91 326.398,275.586C324.744,273.578 323.938,271.164 323.938,268.763L323.938,271.377C323.938,273.777 324.744,276.195 326.398,278.199C326.67,278.525 326.957,278.832 327.254,279.115C329.328,281.111 332.052,282.138 334.797,282.138C337.213,282.138 339.637,281.342 341.647,279.709L342.119,276.266Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M323.938,271.377L323.938,268.763C323.938,271.164 324.744,273.578 326.398,275.586C326.67,275.91 326.957,276.221 327.254,276.5C329.328,278.494 332.052,279.525 334.797,279.525C337.213,279.525 339.637,278.726 341.647,277.092L341.647,279.709C339.637,281.342 337.213,282.138 334.797,282.138C332.052,282.138 329.328,281.111 327.254,279.115C326.957,278.832 326.67,278.525 326.398,278.199C324.744,276.195 323.938,273.777 323.938,271.377Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M330.023,271.421C331.6,271.408 332.85,270.113 332.832,268.564C332.806,267.009 331.531,265.771 329.967,265.771C329.959,265.771 329.951,265.771 329.941,265.775C328.383,265.8 327.117,267.08 327.147,268.644C327.158,270.177 328.42,271.421 329.975,271.421C329.99,271.421 330.008,271.421 330.023,271.421M363.068,265.439L366.994,269.104L365.217,272.404L344.85,272.688C344.806,272.826 344.592,273.32 344.226,273.98C343.926,274.56 343.56,275.129 343.111,275.641C342.703,276.152 342.214,276.65 341.647,277.092C339.637,278.726 337.213,279.525 334.797,279.525C332.052,279.525 329.328,278.494 327.254,276.5C326.957,276.221 326.67,275.91 326.398,275.586C322.597,270.976 323.277,264.197 327.92,260.438C329.931,258.796 332.361,258 334.779,258C337.207,258 339.619,258.802 341.58,260.373C343.059,261.461 344.014,263.035 344.063,263.121L345.201,263.174L350.172,263.105L351.922,266.154L356.133,265.759L357.748,267.418L359.226,267.74L363.068,265.439" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M255.528,341.854L255.528,344.467L253.751,347.77L253.751,345.154L255.528,341.854Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M254.528,344.391L253.751,347.77L233.384,348.052L232.966,345.266L254.528,344.391Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M233.382,345.447L233.382,348.06C233.335,348.207 232.751,349.354 232.403,349.984L232.153,346.766C232.501,346.134 233.335,345.593 233.382,345.447Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M233.384,345.438L233.384,348.052L233.382,348.06L233.382,345.447L233.384,345.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M233.384,345.438L233.384,348.052C233.341,348.189 233.126,348.685 232.761,349.343L232.761,346.73C233.126,346.07 233.341,345.576 233.384,345.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M233.153,345.953L232.81,349.218C232.534,349.718 231.886,350.725 231.497,351.171L231.528,348.453C231.917,348.002 232.94,346.391 233.153,345.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M232.966,346.328L232.761,349.343C232.46,349.927 232.024,350.537 231.575,351.046L231.645,348.391C232.095,347.879 232.665,346.908 232.966,346.328Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M231.856,348.031L231.716,350.891C231.307,351.402 230.749,352.013 230.181,352.459L229.653,349.641C230.222,349.199 231.448,348.559 231.856,348.031Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M231.731,348.046L231.645,351.004C231.237,351.516 230.706,352.039 230.138,352.484L229.856,349.843C230.425,349.402 231.323,348.559 231.731,348.046Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M230.653,349.016C228.644,350.65 225.747,352.275 223.331,352.275C220.587,352.275 217.862,351.244 215.788,349.25C215.491,348.971 215.204,348.66 214.932,348.336C213.278,346.328 212.472,343.914 212.472,341.513L212.472,344.127C212.472,346.527 213.278,348.945 214.932,350.949C215.204,351.275 215.491,351.582 215.788,351.865C217.862,353.861 220.587,354.888 223.331,354.888C225.747,354.888 228.171,354.092 230.181,352.459L230.653,349.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M212.472,344.127L212.472,341.513C212.472,343.914 213.278,346.328 214.932,348.336C215.204,348.66 215.491,348.971 215.788,349.25C217.862,351.244 220.587,352.275 223.331,352.275C225.747,352.275 228.171,351.476 230.181,349.842L230.181,352.459C228.171,354.092 225.747,354.888 223.331,354.888C220.587,354.888 217.862,353.861 215.788,351.865C215.491,351.582 215.204,351.275 214.932,350.949C213.278,348.945 212.472,346.527 212.472,344.127Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M218.557,344.171C220.134,344.158 221.384,342.863 221.366,341.314C221.341,339.759 220.065,338.521 218.501,338.521C218.493,338.521 218.486,338.521 218.476,338.525C216.917,338.55 215.652,339.83 215.681,341.394C215.693,342.927 216.954,344.171 218.509,344.171C218.524,344.171 218.542,344.171 218.557,344.171M251.602,338.189L255.528,341.854L253.751,345.154L233.384,345.438C233.341,345.576 233.126,346.07 232.761,346.73C232.46,347.31 232.095,347.879 231.645,348.391C231.237,348.902 230.749,349.4 230.181,349.842C228.171,351.476 225.747,352.275 223.331,352.275C220.587,352.275 217.862,351.244 215.788,349.25C215.491,348.971 215.204,348.66 214.932,348.336C211.132,343.726 211.811,336.947 216.454,333.188C218.466,331.546 220.895,330.75 223.314,330.75C225.741,330.75 228.153,331.552 230.115,333.123C231.593,334.211 232.548,335.785 232.597,335.871L233.736,335.924L238.706,335.855L240.456,338.904L244.667,338.509L246.282,340.168L247.761,340.49L251.602,338.189" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M366.994,341.854L366.994,344.467L365.217,347.77L365.217,345.154L366.994,341.854Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M365.994,344.391L365.217,347.77L344.85,348.052L344.431,345.266L365.994,344.391Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.847,345.447L344.847,348.06C344.801,348.207 344.217,349.354 343.869,349.984L343.619,346.766C343.967,346.134 344.801,345.593 344.847,345.447Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.85,345.438L344.85,348.052L344.847,348.06L344.847,345.447L344.85,345.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.85,345.438L344.85,348.052C344.806,348.189 344.592,348.685 344.226,349.343L344.226,346.73C344.592,346.07 344.806,345.576 344.85,345.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.619,345.953L344.275,349.218C344,349.718 343.351,350.725 342.963,351.171L342.994,348.453C343.383,348.002 344.406,346.391 344.619,345.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M344.431,346.328L344.226,349.343C343.926,349.927 343.49,350.537 343.041,351.046L343.111,348.391C343.56,347.879 344.13,346.908 344.431,346.328Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M343.322,348.031L343.181,350.891C342.773,351.402 342.214,352.013 341.647,352.459L341.119,349.641C341.688,349.199 342.914,348.559 343.322,348.031Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M343.197,348.046L343.111,351.004C342.703,351.516 342.172,352.039 341.604,352.484L341.322,349.843C341.89,349.402 342.789,348.559 343.197,348.046Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M342.119,349.016C340.109,350.65 337.213,352.275 334.797,352.275C332.052,352.275 329.328,351.244 327.254,349.25C326.957,348.971 326.67,348.66 326.398,348.336C324.744,346.328 323.938,343.914 323.938,341.513L323.938,344.127C323.938,346.527 324.744,348.945 326.398,350.949C326.67,351.275 326.957,351.582 327.254,351.865C329.328,353.861 332.052,354.888 334.797,354.888C337.213,354.888 339.637,354.092 341.647,352.459L342.119,349.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M323.938,344.127L323.938,341.513C323.938,343.914 324.744,346.328 326.398,348.336C326.67,348.66 326.957,348.971 327.254,349.25C329.328,351.244 332.052,352.275 334.797,352.275C337.213,352.275 339.637,351.476 341.647,349.842L341.647,352.459C339.637,354.092 337.213,354.888 334.797,354.888C332.052,354.888 329.328,353.861 327.254,351.865C326.957,351.582 326.67,351.275 326.398,350.949C324.744,348.945 323.938,346.527 323.938,344.127Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M330.023,344.171C331.6,344.158 332.85,342.863 332.832,341.314C332.806,339.759 331.531,338.521 329.967,338.521C329.959,338.521 329.951,338.521 329.941,338.525C328.383,338.55 327.117,339.83 327.147,341.394C327.158,342.927 328.42,344.171 329.975,344.171C329.99,344.171 330.008,344.171 330.023,344.171M363.068,338.189L366.994,341.854L365.217,345.154L344.85,345.438C344.806,345.576 344.592,346.07 344.226,346.73C343.926,347.31 343.56,347.879 343.111,348.391C342.703,348.902 342.214,349.4 341.647,349.842C339.637,351.476 337.213,352.275 334.797,352.275C332.052,352.275 329.328,351.244 327.254,349.25C326.957,348.971 326.67,348.66 326.398,348.336C322.597,343.726 323.277,336.947 327.92,333.188C329.931,331.546 332.361,330.75 334.779,330.75C337.207,330.75 339.619,331.552 341.58,333.123C343.059,334.211 344.014,335.785 344.063,335.871L345.201,335.924L350.172,335.855L351.922,338.904L356.133,338.509L357.748,340.168L359.226,340.49L363.068,338.189" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M478.459,341.854L478.459,344.467L476.682,347.77L476.682,345.154L478.459,341.854Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M477.459,344.391L476.682,347.77L456.315,348.052L455.897,345.266L477.459,344.391Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M456.313,345.447L456.313,348.06C456.266,348.207 455.682,349.354 455.334,349.984L455.084,346.766C455.432,346.134 456.266,345.593 456.313,345.447Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M456.315,345.438L456.315,348.052L456.313,348.06L456.313,345.447L456.315,345.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M456.315,345.438L456.315,348.052C456.272,348.189 456.057,348.685 455.692,349.343L455.692,346.73C456.057,346.07 456.272,345.576 456.315,345.438Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M456.084,345.953L455.741,349.218C455.466,349.718 454.817,350.725 454.429,351.171L454.459,348.453C454.848,348.002 455.871,346.391 456.084,345.953Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M455.897,346.328L455.692,349.343C455.391,349.927 454.955,350.537 454.507,351.046L454.577,348.391C455.026,347.879 455.596,346.908 455.897,346.328Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M454.788,348.031L454.647,350.891C454.239,351.402 453.68,352.013 453.112,352.459L452.584,349.641C453.153,349.199 454.379,348.559 454.788,348.031Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M454.663,348.046L454.577,351.004C454.168,351.516 453.638,352.039 453.069,352.484L452.788,349.843C453.356,349.402 454.254,348.559 454.663,348.046Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M453.584,349.016C451.575,350.65 448.679,352.275 446.263,352.275C443.518,352.275 440.793,351.244 438.72,349.25C438.422,348.971 438.135,348.66 437.864,348.336C436.209,346.328 435.403,343.914 435.403,341.513L435.403,344.127C435.403,346.527 436.209,348.945 437.864,350.949C438.135,351.275 438.422,351.582 438.72,351.865C440.793,353.861 443.518,354.888 446.263,354.888C448.679,354.888 451.102,354.092 453.112,352.459L453.584,349.016Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M435.403,344.127L435.403,341.513C435.403,343.914 436.209,346.328 437.864,348.336C438.135,348.66 438.422,348.971 438.72,349.25C440.793,351.244 443.518,352.275 446.263,352.275C448.679,352.275 451.102,351.476 453.112,349.842L453.112,352.459C451.102,354.092 448.679,354.888 446.263,354.888C443.518,354.888 440.793,353.861 438.72,351.865C438.422,351.582 438.135,351.275 437.864,350.949C436.209,348.945 435.403,346.527 435.403,344.127Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M441.489,344.171C443.065,344.158 444.315,342.863 444.297,341.314C444.272,339.759 442.996,338.521 441.432,338.521C441.425,338.521 441.417,338.521 441.407,338.525C439.848,338.55 438.583,339.83 438.612,341.394C438.624,342.927 439.886,344.171 441.44,344.171C441.455,344.171 441.473,344.171 441.489,344.171M474.534,338.189L478.459,341.854L476.682,345.154L456.315,345.438C456.272,345.576 456.057,346.07 455.692,346.73C455.391,347.31 455.026,347.879 454.577,348.391C454.168,348.902 453.68,349.4 453.112,349.842C451.102,351.476 448.679,352.275 446.263,352.275C443.518,352.275 440.793,351.244 438.72,349.25C438.422,348.971 438.135,348.66 437.864,348.336C434.063,343.726 434.743,336.947 439.386,333.188C441.397,331.546 443.827,330.75 446.245,330.75C448.672,330.75 451.084,331.552 453.046,333.123C454.524,334.211 455.479,335.785 455.528,335.871L456.667,335.924L461.638,335.855L463.388,338.904L467.598,338.509L469.213,340.168L470.692,340.49L474.534,338.189" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 37 KiB

3
notary/images/metadata-sequence.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 44 KiB

92
notary/images/service-architecture.svg
View File

@ -1,92 +0,0 @@
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 540 388" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.41421;">
<g transform="matrix(1,0,0,1,-35,-200)">
<path d="M353.15,265.5C356.606,265.5 359.389,268.122 359.389,271.34L359.389,364.629C359.389,367.854 356.606,370.5 353.15,370.5L280.854,370.5C277.394,370.5 274.611,367.854 274.611,364.629L274.611,271.34C274.611,268.122 277.394,265.5 280.854,265.5L353.15,265.5Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<g transform="matrix(1,0,0,1,289.6,361.44)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:20px;fill:white;">server</text>
</g>
</g>
<path d="M346.342,287.214L287.646,287.214L287.646,280.689L346.342,280.689L346.342,287.214ZM346.342,298.778L287.646,298.778L287.646,292.253L346.342,292.253L346.342,298.778ZM346.342,309.823L287.646,309.823L287.646,303.303L346.342,303.303L346.342,309.823" style="fill:rgb(255,255,254);fill-rule:nonzero;"/>
<path d="M371.929,318L457.46,318" style="fill:none;stroke-width:3px;stroke:rgb(39,83,126);"/>
<path d="M317,383.04L317,416.96" style="fill:none;stroke-width:3px;stroke:rgb(39,83,126);"/>
<path d="M512.389,383.04L512.389,416.96" style="fill:none;stroke-width:3px;stroke:rgb(39,83,126);"/>
<path d="M156.297,290.891C157.485,290.891 158.432,289.796 158.432,288.441C158.432,287.108 157.485,286.004 156.297,286.004L134.119,286.004C132.932,286.004 131.97,287.108 131.97,288.441C131.97,289.796 132.932,290.891 134.119,290.891L156.297,290.891M158.653,279.898C161.611,279.898 164,282.618 164,285.991L164,290.891C164,294.265 161.611,297.002 158.653,297.002L99.332,297.002C96.39,297.002 94,294.265 94,290.891L94,285.991C94,282.618 96.39,279.898 99.332,279.898L158.653,279.898" style="fill:black;fill-rule:nonzero;"/>
<path d="M158.226,263.71L158.226,229.227C158.226,227.697 157.139,226.456 155.791,226.456L102.133,226.456C100.803,226.456 99.713,227.697 99.713,229.227L99.713,263.71C99.713,265.242 100.803,266.487 102.133,266.487L155.791,266.487C157.139,266.487 158.226,265.242 158.226,263.71M155.791,220C160.251,220 163.892,224.146 163.892,229.227L163.892,263.71C163.892,268.793 160.251,272.941 155.791,272.941L102.133,272.941C97.672,272.941 94.05,268.793 94.05,263.71L94.05,229.227C94.05,224.146 97.672,220 102.133,220L155.791,220" style="fill:black;fill-rule:nonzero;"/>
<g transform="matrix(1,0,0,1,108.498,251.501)">
<g>
<text x="0px" y="0px" style="font-family:'CourierNewPS-BoldMT';font-size:20px;fill:black;">&gt;_</text>
</g>
</g>
<path d="M156.297,425.891C157.485,425.891 158.432,424.796 158.432,423.441C158.432,422.108 157.485,421.004 156.297,421.004L134.119,421.004C132.932,421.004 131.97,422.108 131.97,423.441C131.97,424.796 132.932,425.891 134.119,425.891L156.297,425.891M158.653,414.898C161.611,414.898 164,417.618 164,420.991L164,425.891C164,429.265 161.611,432.002 158.653,432.002L99.332,432.002C96.39,432.002 94,429.265 94,425.891L94,420.991C94,417.618 96.39,414.898 99.332,414.898L158.653,414.898" style="fill:black;fill-rule:nonzero;"/>
<path d="M158.226,398.71L158.226,364.227C158.226,362.697 157.139,361.456 155.791,361.456L102.133,361.456C100.803,361.456 99.713,362.697 99.713,364.227L99.713,398.71C99.713,400.242 100.803,401.487 102.133,401.487L155.791,401.487C157.139,401.487 158.226,400.242 158.226,398.71M155.791,355C160.251,355 163.892,359.146 163.892,364.227L163.892,398.71C163.892,403.793 160.251,407.941 155.791,407.941L102.133,407.941C97.672,407.941 94.05,403.793 94.05,398.71L94.05,364.227C94.05,359.146 97.672,355 102.133,355L155.791,355" style="fill:black;fill-rule:nonzero;"/>
<g transform="matrix(1,0,0,1,108.498,386.501)">
<g>
<text x="0px" y="0px" style="font-family:'CourierNewPS-BoldMT';font-size:20px;fill:black;">&gt;_</text>
</g>
</g>
<path d="M156.297,560.891C157.485,560.891 158.432,559.796 158.432,558.441C158.432,557.108 157.485,556.004 156.297,556.004L134.119,556.004C132.932,556.004 131.97,557.108 131.97,558.441C131.97,559.796 132.932,560.891 134.119,560.891L156.297,560.891M158.653,549.898C161.611,549.898 164,552.618 164,555.991L164,560.891C164,564.265 161.611,567.002 158.653,567.002L99.332,567.002C96.39,567.002 94,564.265 94,560.891L94,555.991C94,552.618 96.39,549.898 99.332,549.898L158.653,549.898" style="fill:black;fill-rule:nonzero;"/>
<path d="M158.226,533.71L158.226,499.227C158.226,497.697 157.139,496.456 155.791,496.456L102.133,496.456C100.803,496.456 99.713,497.697 99.713,499.227L99.713,533.71C99.713,535.242 100.803,536.487 102.133,536.487L155.791,536.487C157.139,536.487 158.226,535.242 158.226,533.71M155.791,490C160.251,490 163.892,494.146 163.892,499.227L163.892,533.71C163.892,538.793 160.251,542.941 155.791,542.941L102.133,542.941C97.672,542.941 94.05,538.793 94.05,533.71L94.05,499.227C94.05,494.146 97.672,490 102.133,490L155.791,490" style="fill:black;fill-rule:nonzero;"/>
<g transform="matrix(1,0,0,1,108.498,521.501)">
<g>
<text x="0px" y="0px" style="font-family:'CourierNewPS-BoldMT';font-size:20px;fill:black;">&gt;_</text>
</g>
</g>
<path d="M176.54,258.501L213.54,258.501C216.854,258.501 219.54,261.188 219.54,264.501L219.54,312C219.54,315.314 222.226,318 225.54,318L262.071,318" style="fill:none;stroke-width:3px;stroke:rgb(39,83,126);"/>
<path d="M176.54,393.501L213.54,393.501C216.854,393.501 219.54,390.815 219.54,387.501L219.54,324C219.54,320.686 222.226,318 225.54,318L262.071,318" style="fill:none;stroke-width:3px;stroke:rgb(39,83,126);"/>
<path d="M176.54,528.501L213.54,528.501C216.854,528.501 219.54,525.815 219.54,522.501L219.54,324C219.54,320.686 222.226,318 225.54,318L262.071,318" style="fill:none;stroke-width:3px;stroke:rgb(39,83,126);"/>
<g transform="matrix(-3.82857e-16,-1,1,-3.82857e-16,84.65,362.114)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:25px;fill:black;">clients</text>
</g>
</g>
<path d="M318.367,475.198C317.805,475.336 317.234,475.472 316.628,475.604C316.307,475.67 315.968,475.736 318.367,475.198Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M316.925,429.5C324.777,429.5 331.487,430.079 337.003,431.008C348.824,432.951 355.128,436.31 355.128,438.372C355.128,440.431 348.824,443.815 337.003,445.764C331.487,446.668 324.777,447.269 316.925,447.269C292.229,447.269 278.75,441.385 278.75,438.372C278.75,435.362 292.229,429.5 316.925,429.5Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M355.128,438.372L355.128,442.868C355.128,444.927 348.824,448.311 337.003,450.254C331.487,451.157 324.777,451.765 316.925,451.765C292.229,451.765 278.75,445.881 278.75,442.868L278.75,438.372C278.75,441.385 292.229,447.269 316.925,447.269C324.777,447.269 331.487,446.668 337.003,445.764C348.824,443.815 355.128,440.431 355.128,438.372Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M355.128,438.372L355.128,442.868C355.128,442.928 355.121,442.994 355.111,443.053L355.111,438.561C355.121,438.498 355.128,438.438 355.128,438.372Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M355.111,438.561L355.111,443.053C355.096,443.135 355.072,443.22 355.039,443.309L355.039,438.81C355.072,438.728 355.096,438.643 355.111,438.561Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M355.039,438.81L355.039,443.309C354.992,443.431 354.927,443.554 354.843,443.683L354.843,439.187C354.927,439.058 354.992,438.932 355.039,438.81Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M354.843,439.187L354.843,443.683C353.494,445.739 347.37,448.55 337.003,450.254C331.487,451.157 324.777,451.765 316.925,451.765C292.229,451.765 278.75,445.881 278.75,442.868L278.75,438.372C278.75,441.385 292.229,447.269 316.925,447.269C324.777,447.269 331.487,446.668 337.003,445.764C347.37,444.058 353.494,441.243 354.843,439.187Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M355.07,506.007C355.152,505.797 355.194,505.598 355.194,505.407L355.194,512.672C355.194,512.757 355.187,512.839 355.172,512.921C355.152,513.028 355.121,513.138 355.08,513.255L355.07,513.272C355.065,513.286 355.053,513.303 355.046,513.318C354.99,513.451 354.925,513.586 354.834,513.727C354.812,513.761 354.775,513.798 354.749,513.834C354.683,513.927 354.601,514.023 354.52,514.118C354.418,514.24 354.309,514.361 354.184,514.487C354.08,514.588 353.966,514.69 353.847,514.793C353.701,514.917 353.545,515.042 353.377,515.166C353.236,515.271 353.09,515.377 352.93,515.484C352.742,515.611 352.533,515.737 352.319,515.863C352.142,515.97 351.966,516.076 351.771,516.183C351.527,516.315 351.257,516.446 350.987,516.576C350.78,516.678 350.583,516.779 350.359,516.88C350.031,517.028 349.666,517.172 349.302,517.318C349.095,517.401 348.909,517.484 348.691,517.567C348.102,517.786 347.472,518.005 346.796,518.218C346.575,518.287 346.322,518.354 346.091,518.422C345.605,518.566 345.118,518.709 344.591,518.847C344.277,518.931 343.936,519.008 343.606,519.088C343.117,519.207 342.628,519.325 342.106,519.438C341.735,519.518 341.343,519.594 340.953,519.67C340.429,519.773 339.897,519.876 339.34,519.973C338.919,520.047 338.482,520.116 338.042,520.186C337.468,520.277 336.877,520.363 336.269,520.447C335.811,520.51 335.342,520.57 334.863,520.63C334.221,520.707 333.559,520.778 332.883,520.846C332.394,520.897 331.905,520.947 331.395,520.992C330.668,521.056 329.911,521.11 329.149,521.163C328.644,521.198 328.151,521.235 327.63,521.265C326.762,521.314 325.852,521.35 324.938,521.383C324.477,521.401 324.038,521.424 323.564,521.438C322.156,521.477 320.704,521.5 319.191,521.5C305.275,521.5 294.762,519.857 287.937,517.838C282.854,516.167 279.215,514.341 278.808,512.924L278.808,505.662C279.186,506.977 282.382,508.652 286.916,510.223L286.824,509.78C293.648,511.795 305.275,514.236 319.191,514.236C320.706,514.236 322.16,514.212 323.569,514.174C324.028,514.159 324.459,514.137 324.908,514.12C325.835,514.086 326.759,514.049 327.641,514.001C328.145,513.97 328.623,513.935 329.113,513.9C329.894,513.847 330.672,513.792 331.416,513.726C331.901,513.683 332.372,513.636 332.842,513.586C333.545,513.516 334.236,513.44 334.904,513.36C335.351,513.305 335.788,513.248 336.221,513.19C336.869,513.102 337.499,513.009 338.112,512.911L346.748,510.971C347.46,510.747 348.122,510.519 348.739,510.286L350.411,509.595C350.553,509.53 350.678,509.466 350.814,509.401C351.169,509.233 351.512,509.063 351.823,508.892C351.964,508.816 352.09,508.738 352.22,508.661C352.492,508.504 352.749,508.346 352.981,508.189C353.1,508.109 353.212,508.028 353.321,507.947C353.528,507.795 353.718,507.644 353.888,507.496C353.981,507.414 354.071,507.333 354.155,507.254C354.306,507.107 354.435,506.964 354.552,506.821C354.617,506.744 354.683,506.665 354.737,506.59L355.07,506.007Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M336.541,452.99C335.488,453.175 334.439,453.314 333.386,453.459C332.844,453.522 332.302,453.619 331.738,453.663C330.767,453.78 329.77,453.871 328.77,453.962C328.121,454.013 327.472,454.079 326.825,454.104C325.556,454.195 324.262,454.265 322.963,454.309L322.316,454.331C320.808,454.406 319.269,454.428 317.673,454.45C317.351,454.45 317.027,454.45 316.677,454.45C301.506,454.45 286.229,452.039 278.808,447.433L278.808,508.431C279.212,509.845 282.826,511.674 287.877,513.343C294.704,515.358 305.23,517.004 319.16,517.004C344.612,517.004 355.194,511.259 355.194,508.176L355.25,446.876C351.281,449.448 344.856,451.645 336.541,452.99Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<g transform="matrix(1,0,0,1,298.329,489.16)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:20px;fill:white;">TUF</text>
</g>
</g>
<g transform="matrix(1,0,0,1,291.982,513.346)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:11px;fill:white;">(server DB)</text>
</g>
</g>
<path d="M513.755,475.198C513.194,475.336 512.623,475.472 512.016,475.604C511.696,475.67 511.356,475.736 513.755,475.198Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M512.314,429.5C520.166,429.5 526.876,430.079 532.392,431.008C544.212,432.951 550.516,436.31 550.516,438.372C550.516,440.431 544.212,443.815 532.392,445.764C526.876,446.668 520.166,447.269 512.314,447.269C487.618,447.269 474.139,441.385 474.139,438.372C474.139,435.362 487.618,429.5 512.314,429.5Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M550.516,438.372L550.516,442.868C550.516,444.927 544.212,448.311 532.392,450.254C526.876,451.157 520.166,451.765 512.314,451.765C487.618,451.765 474.139,445.881 474.139,442.868L474.139,438.372C474.139,441.385 487.618,447.269 512.314,447.269C520.166,447.269 526.876,446.668 532.392,445.764C544.212,443.815 550.516,440.431 550.516,438.372Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M550.516,438.372L550.516,442.868C550.516,442.928 550.51,442.994 550.5,443.053L550.5,438.561C550.51,438.498 550.516,438.438 550.516,438.372Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M550.5,438.561L550.5,443.053C550.485,443.135 550.461,443.22 550.428,443.309L550.428,438.81C550.461,438.728 550.485,438.643 550.5,438.561Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M550.428,438.81L550.428,443.309C550.381,443.431 550.316,443.554 550.231,443.683L550.231,439.187C550.316,439.058 550.381,438.932 550.428,438.81Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M550.231,439.187L550.231,443.683C548.883,445.739 542.758,448.55 532.392,450.254C526.876,451.157 520.166,451.765 512.314,451.765C487.618,451.765 474.139,445.881 474.139,442.868L474.139,438.372C474.139,441.385 487.618,447.269 512.314,447.269C520.166,447.269 526.876,446.668 532.392,445.764C542.758,444.058 548.883,441.243 550.231,439.187Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M550.459,506.007C550.54,505.797 550.582,505.598 550.582,505.407L550.582,512.672C550.582,512.757 550.576,512.839 550.561,512.921C550.54,513.028 550.51,513.138 550.469,513.255L550.459,513.272C550.454,513.286 550.442,513.303 550.435,513.318C550.379,513.451 550.314,513.586 550.223,513.727C550.201,513.761 550.163,513.798 550.138,513.834C550.072,513.927 549.99,514.023 549.908,514.118C549.807,514.24 549.698,514.361 549.572,514.487C549.469,514.588 549.355,514.69 549.236,514.793C549.09,514.917 548.934,515.042 548.766,515.166C548.624,515.271 548.479,515.377 548.319,515.484C548.131,515.611 547.921,515.737 547.707,515.863C547.531,515.97 547.354,516.076 547.159,516.183C546.916,516.315 546.646,516.446 546.376,516.576C546.169,516.678 545.972,516.779 545.747,516.88C545.42,517.028 545.055,517.172 544.691,517.318C544.484,517.401 544.297,517.484 544.08,517.567C543.491,517.786 542.86,518.005 542.184,518.218C541.964,518.287 541.711,518.354 541.479,518.422C540.993,518.566 540.507,518.709 539.98,518.847C539.666,518.931 539.324,519.008 538.995,519.088C538.506,519.207 538.017,519.325 537.495,519.438C537.123,519.518 536.731,519.594 536.342,519.67C535.818,519.773 535.286,519.876 534.729,519.973C534.307,520.047 533.871,520.116 533.431,520.186C532.857,520.277 532.266,520.363 531.658,520.447C531.2,520.51 530.731,520.57 530.252,520.63C529.61,520.707 528.948,520.778 528.272,520.846C527.783,520.897 527.293,520.947 526.784,520.992C526.057,521.056 525.299,521.11 524.537,521.163C524.033,521.198 523.54,521.235 523.018,521.265C522.151,521.314 521.24,521.35 520.327,521.383C519.866,521.401 519.427,521.424 518.952,521.438C517.545,521.477 516.093,521.5 514.58,521.5C500.663,521.5 490.151,519.857 483.325,517.838C478.243,516.167 474.604,514.341 474.196,512.924L474.196,505.662C474.575,506.977 477.771,508.652 482.304,510.223L482.212,509.78C489.037,511.795 500.663,514.236 514.58,514.236C516.095,514.236 517.548,514.212 518.958,514.174C519.416,514.159 519.848,514.137 520.296,514.12C521.224,514.086 522.147,514.049 523.029,514.001C523.533,513.97 524.012,513.935 524.501,513.9C525.283,513.847 526.06,513.792 526.804,513.726C527.29,513.683 527.761,513.636 528.231,513.586C528.934,513.516 529.625,513.44 530.293,513.36C530.74,513.305 531.177,513.248 531.609,513.19C532.257,513.102 532.888,513.009 533.501,512.911L542.137,510.971C542.848,510.747 543.51,510.519 544.127,510.286L545.8,509.595C545.941,509.53 546.067,509.466 546.203,509.401C546.558,509.233 546.9,509.063 547.211,508.892C547.353,508.816 547.479,508.738 547.609,508.661C547.881,508.504 548.138,508.346 548.37,508.189C548.489,508.109 548.601,508.028 548.71,507.947C548.917,507.795 549.107,507.644 549.277,507.496C549.37,507.414 549.46,507.333 549.544,507.254C549.695,507.107 549.824,506.964 549.941,506.821C550.006,506.744 550.072,506.665 550.126,506.59L550.459,506.007Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M531.93,452.99C530.877,453.175 529.827,453.314 528.774,453.459C528.233,453.522 527.691,453.619 527.127,453.663C526.155,453.78 525.159,453.871 524.158,453.962C523.509,454.013 522.861,454.079 522.213,454.104C520.945,454.195 519.651,454.265 518.351,454.309L517.704,454.331C516.196,454.406 514.658,454.428 513.061,454.45C512.74,454.45 512.416,454.45 512.066,454.45C496.894,454.45 481.618,452.039 474.196,447.433L474.196,508.431C474.601,509.845 478.215,511.674 483.266,513.343C490.093,515.358 500.619,517.004 514.549,517.004C540,517.004 550.582,511.259 550.582,508.176L550.639,446.876C546.669,449.448 540.245,451.645 531.93,452.99Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M518.054,478.3L506.811,478.3L506.847,469.639C506.842,464.329 512.469,464.349 512.469,464.349C517.85,464.365 518.09,469.639 518.09,469.639L518.054,478.3ZM523.396,478.3L523.396,469.639C522.816,463.932 518.112,459.5 512.469,459.5C506.811,459.5 502.1,463.91 501.541,469.639L501.541,478.3L495.889,478.3L495.889,497.5L528.889,497.5L528.889,478.3L523.396,478.3" style="fill:black;fill-rule:nonzero;"/>
<g transform="matrix(1,0,0,1,485.4,513.346)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:11px;fill:white;">(signer DB)</text>
</g>
</g>
<path d="M548.539,265.5C551.995,265.5 554.777,268.122 554.777,271.34L554.777,364.629C554.777,367.854 551.995,370.5 548.539,370.5L476.243,370.5C472.782,370.5 470,367.854 470,364.629L470,271.34C470,268.122 472.782,265.5 476.243,265.5L548.539,265.5Z" style="fill:rgb(58,142,237);fill-rule:nonzero;"/>
<path d="M541.731,287.214L483.034,287.214L483.034,280.689L541.731,280.689L541.731,287.214ZM541.731,298.778L483.034,298.778L483.034,292.253L541.731,292.253L541.731,298.778ZM541.731,309.823L483.034,309.823L483.034,303.303L541.731,303.303L541.731,309.823" style="fill:rgb(255,255,254);fill-rule:nonzero;"/>
<path d="M487.696,343.169C489.099,343.157 490.213,342.004 490.197,340.624C490.176,339.24 489.039,338.137 487.646,338.137C487.638,338.137 487.633,338.137 487.623,338.141C486.235,338.162 485.108,339.303 485.135,340.695C485.144,342.061 486.267,343.169 487.652,343.169C487.666,343.169 487.683,343.169 487.696,343.169M517.125,337.842L520.621,341.104L519.039,344.044L500.9,344.296C500.862,344.42 500.671,344.86 500.346,345.448C500.078,345.964 499.752,346.471 499.351,346.926C498.988,347.382 498.554,347.825 498.047,348.219C496.258,349.674 494.099,350.386 491.947,350.386C489.504,350.386 487.077,349.467 485.23,347.691C484.965,347.444 484.709,347.166 484.469,346.877C481.083,342.773 481.688,336.735 485.823,333.387C487.615,331.926 489.779,331.215 491.931,331.215C494.094,331.215 496.242,331.931 497.988,333.329C499.305,334.298 500.156,335.699 500.199,335.777L501.213,335.823L505.64,335.762L507.198,338.479L510.949,338.127L512.388,339.604L513.704,339.891L517.125,337.842" style="fill:black;fill-rule:nonzero;"/>
<path d="M522.525,323.716C521.122,323.729 520.009,324.881 520.024,326.262C520.047,327.646 521.183,328.748 522.576,328.748C522.583,328.748 522.59,328.748 522.598,328.744C523.986,328.723 525.113,327.583 525.088,326.19C525.077,324.824 523.954,323.716 522.569,323.716C522.555,323.716 522.539,323.716 522.525,323.716M493.097,329.044L489.601,325.782L491.183,322.842L509.322,322.589C509.359,322.465 509.551,322.025 509.877,321.438C510.144,320.921 510.47,320.415 510.869,319.959C511.233,319.504 511.668,319.061 512.174,318.666C513.965,317.211 516.123,316.5 518.274,316.5C520.719,316.5 523.144,317.418 524.992,319.194C525.256,319.443 525.512,319.719 525.754,320.008C529.138,324.114 528.533,330.15 524.398,333.498C522.607,334.959 520.443,335.67 518.291,335.67C516.128,335.67 513.98,334.956 512.234,333.557C510.916,332.588 510.066,331.186 510.022,331.109L509.009,331.062L504.582,331.123L503.023,328.407L499.273,328.759L497.834,327.282L496.517,326.995L493.097,329.044" style="fill:white;fill-rule:nonzero;"/>
<path d="M542.499,350.386C542.499,357.574 536.672,363.402 529.484,363.402C522.295,363.402 516.468,357.574 516.468,350.386C516.468,343.197 522.295,337.37 529.484,337.37C536.672,337.37 542.499,343.197 542.499,350.386Z" style="fill:white;fill-rule:nonzero;"/>
<path d="M542.499,350.386C542.499,357.574 536.672,363.402 529.484,363.402C522.295,363.402 516.468,357.574 516.468,350.386C516.468,343.197 522.295,337.37 529.484,337.37C536.672,337.37 542.499,343.197 542.499,350.386Z" style="fill:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(46,47,45);"/>
<path d="M530.553,342.21L530.484,353.585" style="fill:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(46,47,45);"/>
<path d="M524.053,352.449L531.053,352.449" style="fill:none;stroke-width:1px;stroke:black;"/>
<g transform="matrix(1,0,0,1,475.18,362.346)">
<g>
<text x="0px" y="0px" style="font-family:'HelveticaNeue-Medium';font-size:11px;fill:white;">(signer)</text>
</g>
</g>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 22 KiB

3
notary/images/service-deployment.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 32 KiB

BIN
notary/images/trust-pinning-flow.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 46 KiB

13
notary/index.md
View File

@ -1,13 +0,0 @@
---
description: List of Notary Documentation
keywords: docker, notary, trust, image, signing, repository, tuf
title: Notary
notoc: true
---
* [Getting Started](getting_started.md)
* [Advanced Usage](advanced_usage.md)
* [Service Architecture](service_architecture.md)
* [Running a Service](running_a_service.md)
* [Configuration files](reference/index.md)
* [Changelog](changelog.md)

183
notary/reference/client-config.md
View File

@ -1,183 +0,0 @@
---
description: Configuring the Notary client, server and signer.
keywords: docker, notary, notary-client, notary-server, notary server, notary-signer, notary signer
title: Notary client configuration file
---
This document is for power users of the [Notary client](../advanced_usage.md)
who want to facilitate CLI interaction or specify custom options.
The configuration file for Notary client normally resides at `~/.notary/config.json`,
but the path to a different configuration file can be specified using the
`-c` or `--configFile` command line flag.
## Overview of the file
In addition to the configuration file format, see the optional password
[environment variables](client-config.md#environment-variables-optional) that the Notary client
can take for ease of use.
Here is a full client configuration file example; click on the top level
JSON keys to learn more about the configuration section corresponding to that key:
<pre><code class="language-json">{
<a href="#trust_dir-section-optional">"trust_dir"</a> : "~/.docker/trust",
<a href="#remote_server-section-optional">"remote_server"</a>: {
"url": "https://my-notary-server.my-private-registry.com",
"root_ca": "./fixtures/root-ca.crt",
"tls_client_cert": "./fixtures/secure.example.com.crt",
"tls_client_key": "./fixtures/secure.example.com.crt"
},
<a href="#trust_pinning-section-optional">"trust_pinning"</a>: {
"certs": {
"docker.com/notary": ["49cf5c6404a35fa41d5a5aa2ce539dfee0d7a2176d0da488914a38603b1f4292"]
}
}
}
</code></pre>
## trust_dir section (optional)
The `trust_dir` specifies the location (as an absolute path or a path
relative to the directory of the configuration file) where the TUF metadata
and private keys are stored.
This is normally defaults to `~/.notary`, but specifying `~/.docker/trust`
facilitates interoperability with content trust.
This option can be overridden with the command line flag `--trustDir`.
## remote_server section (optional)
The `remote_server` specifies how to connect to a Notary server to download
metadata updates and publish metadata changes.
Remote server example:
```json
"remote_server": {
"url": "https://my-notary-server.my-private-registry.com",
"root_ca": "./fixtures/root-ca.crt",
"tls_client_cert": "./fixtures/secure.example.com.crt",
"tls_client_key": "./fixtures/secure.example.com.crt"
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>url</code></td>
<td valign="top">no</td>
<td valign="top">URL of the Notary server: defaults to https://notary.docker.io
This configuration option can be overridden with the command line flag
`-s` or `--server`.</td>
</tr>
<tr>
<td valign="top"><code>root_ca</code></td>
<td valign="top">no</td>
<td valign="top"><p>The path to the file containing the root CA with which to verify
the TLS certificate of the Notary server, for example if it is self-signed.
The path is relative to the directory of the configuration file.</p>
<p>This configuration option can overridden with the command line flag
`--tlscacert`, which would specify a path relative to the current working
directory where the Notary client is invoked.</p></td>
</tr>
<tr>
<td valign="top"><code>tls_client_cert</code></td>
<td valign="top">no</td>
<td valign="top"><p>The path to the client certificate to use for mutual TLS with
the Notary server. Must be provided along with <code>tls_client_key</code>
or not provided at all. The path is relative to the directory of the
configuration file.</p>
<p>This configuration option can overridden with the command line flag
`--tlscert`, which would specify a path relative to the current working
directory where the Notary client is invoked.</p></td>
</tr>
<tr>
<td valign="top"><code>tls_client_key</code></td>
<td valign="top">no</td>
<td valign="top"><p>The path to the client key to use for mutual TLS with
the Notary server. Must be provided along with <code>tls_client_cert</code>
or not provided at all. The path is relative to the directory of the
configuration file.</p>
<p>This configuration option can overridden with the command line flag
`--tlskey`, which would specify a path relative to the current working
directory where the Notary client is invoked.</p></td>
</tr>
</table>
## trust_pinning section (optional)
The `trust_pinning` specifies how to bootstrap trust for the root of a
Notary client's trusted collection.
This section is optional, Notary uses TOFU over HTTPS by default and
trust certificates in the downloaded root file.
In this section, one can provide specific certificates to pin to, or a CA
to pin to as a root of trust for a GUN. Multiple sections can be specified,
but the pinned certificates take highest priority for validation, followed
by the pinned CA, followed by TOFUS (TOFU over HTTPS). The diagram below
describes this validation flow:
![validation flow](https://cdn.rawgit.com/docker/notary/27469f01fe244bdf70f34219616657b336724bc3/docs/images/trust-pinning-flow.png)
Only one trust pinning option is used to validate a GUN even if multiple
sections are specified, and any validation failure results in a failed
bootstrapping of the repo.
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>certs</code></td>
<td valign="top">no</td>
<td valign="top"><p>Mapping of GUN to certificate IDs to pin to.
Both are strings in the JSON object.</p></td>
</tr>
<tr>
<td valign="top"><code>ca</code></td>
<td valign="top">no</td>
<td valign="top"><p>Mapping of GUN prefixes to filepaths containing
the root CA file with which to verify the certificates in the root file.
This file can contain multiple root certificates, bundled in separate
PEM blocks.
The path is relative to the directory of the configuration file.</p></td>
</tr>
<tr>
<td valign="top"><code>disable_tofu</code></td>
<td valign="top">no</td>
<td valign="top"><p>Boolean value determining whether to use trust
on first use when bootstrapping validation on a collection's
root file. This keeps TOFUs on by default.</p></td>
</tr>
</table>
## Environment variables (optional)
The following environment variables containing signing key passphrases can
be used to facilitate [Notary client CLI interaction](../advanced_usage.md).
If provided, these passwords are used initially to sign TUF metadata.
If the passphrase is incorrect, you are prompted to enter the correct
passphrase.
| Environment Variable | Description |
| ----------------------------- | ----------------------------------------- |
|`NOTARY_ROOT_PASSPHRASE` | The root/offline key passphrase |
|`NOTARY_TARGETS_PASSPHRASE` | The targets (an online) key passphrase |
|`NOTARY_SNAPSHOT_PASSPHRASE` | The snapshot (an online) key passphrase |
|`NOTARY_DELEGATION_PASSPHRASE` | The delegation (an online) key passphrase |
|`NOTARY_AUTH` | The notary server credentials: `<username>:<password>` encoded in base64 |
If provided, the passphrase in `NOTARY_DELEGATION_PASSPHRASE`
is tried for all delegation roles that notary attempts to sign with.

93
notary/reference/common-configs.md
View File

@ -1,93 +0,0 @@
---
description: Configuring the notary client, server and signer.
keywords: docker, notary, notary-client, notary-server, notary server, notary-signer, notary signer
title: Configure sections common to Notary server and signer
---
The logging and bug reporting configuration options for both Notary server and
Notary signer have the same keys and format. The following sections provide
further detail.
For full specific configuration information, see the configuration files for the
Notary [server](server-config.md) or [signer](signer-config.md).
## logging section (optional)
The logging section sets the log level of the server. If it is not provided,
the signer/server defaults to an ERROR logging level. However if an explicit
value was provided, it must be a valid value.
Example:
```json
"logging": {
"level": "debug"
}
```
This entire section is optional. However, if you would like to
specify a different log level, then you need the required parameters
below to configure it.
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>level</code></td>
<td valign="top">yes</td>
<td valign="top">One of <code>"debug"</code>, <code>"info"</code>,
<code>"warning"</code>, <code>"error"</code>, <code>"fatal"</code>,
or <code>"panic"</code></td>
</tr>
</table>
## reporting section (optional)
The reporting section contains any configuration for useful for running the
service, such as reporting errors. Currently, Notary only supports reporting errors
to <a href="https://bugsnag.com" target="_blank">Bugsnag</a>.
See <a href="https://github.com/bugsnag/bugsnag-go/" target="_blank">bugsnag-go</a> for more information
about these configuration parameters.
```json
"reporting": {
"bugsnag": {
"api_key": "c9d60ae4c7e70c4b6c4ebd3e8056d2b8",
"release_stage": "production"
}
}
```
This entire section is optional. If you want to report errors to
Bugsnag, then you need to include a `bugsnag` subsection, along with the
required parameters below, to configure it.
**Bugsnag reporting:**
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>api_key</code></td>
<td valign="top">yes</td>
<td>The BugSnag API key to use to report errors.</td>
</tr>
<tr>
<td valign="top"><code>release_stage</code></td>
<td valign="top">yes</td>
<td>The current release stage, such as <code>"production"</code>. You can
use this value to filter errors in the Bugsnag dashboard.</td>
</tr>
</table>
## Related information
* [Notary Server Configuration File](server-config.md)
* [Notary Signer Configuration File](signer-config.md)

16
notary/reference/index.md
View File

@ -1,16 +0,0 @@
---
description: Configuring the notary client, server and signer.
keywords: docker, notary, notary-client, notary-server, notary server, notary-signer, notary signer
title: Notary configuration files
---
This document is for power users of the [notary client](../advanced_usage.md),
or for those who are [running their own service](../running_a_service.md) who
want to facilitate CLI interaction or specify custom options.
You can configure the following aspects of Notary:
* [Notary Client Configuration File](client-config.md)
* [Notary Server Configuration File](server-config.md)
* [Notary Signer Configuration File](signer-config.md)
* [Configuration sections common to the Notary Server and Signer](common-configs.md)

410
notary/reference/server-config.md
View File

@ -1,410 +0,0 @@
---
description: Configuring the notary client, server and signer.
keywords: docker, notary, notary-client, notary-server, notary server, notary-signer, notary signer
title: Notary server configuration file
---
This document is for those who are [running their own Notary service](../running_a_service.md)
and want to specify custom options.
## Overview
A configuration file is required by Notary server, and the path to the
configuration file must be specified using the `-config` option on the command
line.
Notary server also allows you to [increase/decrease](server-config.md#hot-logging-level-reload) the logging level without having to restart.
Here is a full server configuration file example:
```json
{
"server": {
"http_addr": ":4443",
"tls_key_file": "./fixtures/notary-server.key",
"tls_cert_file": "./fixtures/notary-server.crt"
},
"trust-service": {
"type": "remote",
"hostname": "notarysigner",
"port": "7899",
"key_algorithm": "ecdsa",
"tls_ca_file": "./fixtures/root-ca.crt",
"tls_client_cert": "./fixtures/notary-server.crt",
"tls_client_key": "./fixtures/notary-server.key"
},
"storage": {
"backend": "mysql",
"db_url": "user:pass@tcp(notarymysql:3306)/databasename?parseTime=true"
},
"auth": {
"type": "token",
"options": {
"realm": "https://auth.docker.io/token",
"service": "notary-server",
"issuer": "auth.docker.io",
"rootcertbundle": "/path/to/auth.docker.io/cert"
}
},
"logging": {
"level": "debug"
},
"reporting": {
"bugsnag": {
"api_key": "c9d60ae4c7e70c4b6c4ebd3e8056d2b8",
"release_stage": "production"
}
},
"caching": {
"max_age": {
"current_metadata": 300,
"consistent_metadata": 31536000,
}
},
"repositories": {
"gun_prefixes": ["docker.io/", "my-own-registry.com/"]
}
}
```
For details on the `reporting` and `logging` sections, see the documentation on
[common Notary configuration sections](/notary/reference/common-configs/).
## server section (required)
Example:
```json
"server": {
"http_addr": ":4443",
"tls_key_file": "./fixtures/notary-server.key",
"tls_cert_file": "./fixtures/notary-server.crt"
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>http_addr</code></td>
<td valign="top">yes</td>
<td valign="top">The TCP address (IP and port) to listen on. Examples:
<ul>
<li><code>":4443"</code> means listen on port 4443 on all IPs (and
hence all interfaces, such as those listed when you run
<code>ifconfig</code>)</li>
<li><code>"127.0.0.1:4443"</code> means listen on port 4443 on
localhost only. That means that the server is not
accessible except locally (via SSH tunnel, or just on a local
terminal)</li>
</ul>
</td>
</tr>
<tr>
<td valign="top"><code>tls_key_file</code></td>
<td valign="top">no</td>
<td valign="top">The path to the private key to use for
HTTPS. Must be provided together with <code>tls_cert_file</code>,
or not at all. If neither are provided, the server uses HTTP
instead of HTTPS. The path is relative to the directory of the
configuration file.</td>
</tr>
<tr>
<td valign="top"><code>tls_cert_file</code></td>
<td valign="top">no</td>
<td valign="top">The path to the certificate to use for HTTPS.
Must be provided together with <code>tls_key_file</code>, or not
at all. If neither are provided, the server uses HTTP instead
of HTTPS. The path is relative to the directory of the
configuration file.</td>
</tr>
</table>
## trust_service section (required)
This section configures either a remote trust service, such as
[Notary signer](signer-config.md) or a local in-memory
ED25519 trust service.
Remote trust service example:
```json
"trust_service": {
"type": "remote",
"hostname": "notarysigner",
"port": "7899",
"key_algorithm": "ecdsa",
"tls_ca_file": "./fixtures/root-ca.crt",
"tls_client_cert": "./fixtures/notary-server.crt",
"tls_client_key": "./fixtures/notary-server.key"
}
```
Local trust service example:
```json
"trust_service": {
"type": "local"
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>type</code></td>
<td valign="top">yes</td>
<td valign="top">Must be <code>"remote"</code> or <code>"local"</code></td>
</tr>
<tr>
<td valign="top"><code>hostname</code></td>
<td valign="top">yes if remote</td>
<td valign="top">The hostname of the remote trust service</td>
</tr>
<tr>
<td valign="top"><code>port</code></td>
<td valign="top">yes if remote</td>
<td valign="top">The GRPC port of the remote trust service</td>
</tr>
<tr>
<td valign="top"><code>key_algorithm</code></td>
<td valign="top">yes if remote</td>
<td valign="top">Algorithm to use to generate keys stored on the
signing service. Valid values are <code>"ecdsa"</code>,
<code>"rsa"</code>, and <code>"ed25519"</code>.</td>
</tr>
<tr>
<td valign="top"><code>tls_ca_file</code></td>
<td valign="top">no</td>
<td valign="top">The path to the root CA that signed the TLS
certificate of the remote service. This parameter must be
provided if said root CA is not in the system's default trust
roots. The path is relative to the directory of the configuration file.</td>
</tr>
<tr>
<td valign="top"><code>tls_client_key</code></td>
<td valign="top">no</td>
<td valign="top">The path to the private key to use for TLS mutual
authentication. This must be provided together with
<code>tls_client_cert</code> or not at all. The path is relative
to the directory of the configuration file.</td>
</tr>
<tr>
<td valign="top"><code>tls_client_cert</code></td>
<td valign="top">no</td>
<td valign="top">The path to the certificate to use for TLS mutual
authentication. This must be provided together with
<code>tls_client_key</code> or not at all. The path is relative
to the directory of the configuration file.</td>
</tr>
</table>
## storage section (required)
The storage section specifies which storage backend the server should use to
store TUF metadata. Only MySQL or an in-memory store is supported.
DB storage example:
```json
"storage": {
"backend": "mysql",
"db_url": "user:pass@tcp(notarymysql:3306)/databasename?parseTime=true"
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>backend</code></td>
<td valign="top">yes</td>
<td valign="top">Must be <code>"mysql"</code> or <code>"memory"</code>.
If <code>"memory"</code> is selected, the <code>db_url</code>
is ignored.</td>
</tr>
<tr>
<td valign="top"><code>db_url</code></td>
<td valign="top">yes if not <code>memory</code></td>
<td valign="top">The <a href="https://github.com/go-sql-driver/mysql">
the Data Source Name used to access the DB.</a>
( include <code>parseTime=true</code> as part of the DSN)</td>
</tr>
</table>
## auth section (optional)
This sections specifies the authentication options for the server.
Currently, we only support token authentication.
Example:
```json
"auth": {
"type": "token",
"options": {
"realm": "https://auth.docker.io",
"service": "notary-server",
"issuer": "auth.docker.io",
"rootcertbundle": "/path/to/auth.docker.io/cert"
}
}
```
This entire section is optional. However, if you would like
authentication for your server, then you need the required parameters below to
configure it.
**Token authentication:**
This is an implementation of the same authentication used by version 2 of the
[Docker Registry](https://github.com/docker/distribution).
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>type</code></td>
<td valign="top">yes</td>
<td valign="top">Must be <code>"token"</code>; all other values result in no
authentication (and the rest of the parameters are ignored)</td>
</tr>
<tr>
<td valign="top"><code>options</code></td>
<td valign="top">yes</td>
<td valign="top">The options for token auth. See
<a href="https://github.com/docker/distribution/blob/master/docs/configuration.md#token">
the registry token configuration documentation</a>
for the parameter details.</td>
</tr>
</table>
## caching section (optional)
Example:
```json
"caching": {
"max_age": {
"current_metadata": 300,
"consistent_metadata": 31536000,
}
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>max_age</code></td>
<td valign="top">no</td>
<td valign="top">The max age, in seconds, for caching services to cache
the latest metadata for a role and the metadata by checksum for a
role. This value is set on the cache control headers for
GET-ting metadata.
`must-revalidate` is also set on the cache control headers
for current metadata, as current metadata may change whenever new
metadata is signed into a repo.
Consistent metadata should never change, although it may be deleted,
so the max age can be a higher value.
</td>
</tr>
</table>
## repositories section (optional)
Example:
```json
"repositories": {
"gun_prefixes": ["docker.io/", "my-own-registry.com/"]
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>gun_prefixes</code></td>
<td valign="top">no</td>
<td valign="top">A list of GUN prefixes accepted by this
server. POST operations on an image beginning with any other prefix
are rejected with a 400, and GET/DELETE operations are rejected
with a 404.
</td>
</tr>
</table>
## Hot logging level reload
We don't support completely reloading notary configuration files yet at present. What we support for now is:
- increase logging level by signaling `SIGUSR1`
- decrease logging level by signaling `SIGUSR2`
Example:
To increase logging level
```bash
$ kill -s SIGUSR1 PID
```
or
```bash
$ docker container exec -i CONTAINER_ID kill -s SIGUSR1 PID
```
To decrease logging level
```bash
$ kill -s SIGUSR2 PID
```
or
```bash
$ docker container exec -i CONTAINER_ID kill -s SIGUSR2 PID
```
PID is the process id of `notary-server` and it may not the PID 1 process if you are running
the container with some kind of wrapper startup script or something.
You can get the PID of `notary-server` through
```bash
$ docker container exec CONTAINER_ID ps aux
```
or
```bash
$ ps aux | grep "notary-server -config" | grep -v "grep"
```
## Related information
* [Notary Signer Configuration File](signer-config.md)
* [Configuration sections common to the Notary Server and Signer](common-configs.md)

235
notary/reference/signer-config.md
View File

@ -1,235 +0,0 @@
---
description: Configuring the notary client, server and signer.
keywords: docker, notary, notary-client, notary-server, notary server, notary-signer, notary signer
title: Notary signer configuration file
---
This document is for those who are [running their own Notary service](../running_a_service.md)
and want to specify custom options.
## Overview
Notary signer [requires environment variables](signer-config.md#environment-variables-required-if-using-mysql)
to encrypt private keys at rest. It also requires a configuration file, the
path to which is specified on the command line using the `-config` flag.
Here is a full signer configuration file example:
```json
{
"server": {
"http_addr": ":4444",
"grpc_addr": ":7899",
"tls_cert_file": "./fixtures/notary-signer.crt",
"tls_key_file": "./fixtures/notary-signer.key",
"client_ca_file": "./fixtures/notary-server.crt"
},
"logging": {
"level": 2
},
"storage": {
"backend": "mysql",
"db_url": "user:pass@tcp(notarymysql:3306)/databasename?parseTime=true",
"default_alias": "passwordalias1"
},
"reporting": {
"bugsnag": {
"api_key": "c9d60ae4c7e70c4b6c4ebd3e8056d2b8",
"release_stage": "production"
}
}
}
```
For details on the `reporting` and `logging` sections, see the documentation on
[common Notary configuration sections](common-configs.md).
## server section (required)
"server" in this case refers to Notary signer's HTTP/GRPC server, not
"Notary server".
Example:
```json
{
"server": {
"http_addr": ":4444",
"grpc_addr": ":7899",
"tls_cert_file": "./fixtures/notary-signer.crt",
"tls_key_file": "./fixtures/notary-signer.key",
"client_ca_file": "./fixtures/notary-server.crt"
}
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>http_addr</code></td>
<td valign="top">yes</td>
<td valign="top">The TCP address (IP and port) to listen for HTTP
traffic on. Examples:
<ul>
<li><code>":4444"</code> means listen on port 4444 on all IPs (and
hence all interfaces, such as those listed when you run
<code>ifconfig</code>)</li>
<li><code>"127.0.0.1:4444"</code> means listen on port 4444 on
localhost only. That means that the server is not
accessible except locally (via SSH tunnel, or just on a local
terminal)</li>
</ul>
</td>
</tr>
<tr>
<td valign="top"><code>grpc_addr</code></td>
<td valign="top">yes</td>
<td valign="top">The TCP address (IP and port) to listen for GRPC
traffic. Examples:
<ul>
<li><code>":7899"</code> means listen on port 7899 on all IPs (and
hence all interfaces, such as those listed when you run
<code>ifconfig</code>)</li>
<li><code>"127.0.0.1:7899"</code> means listen on port 7899 on
localhost only. That means that the server is not
accessible except locally (via SSH tunnel, or just on a local
terminal)</li>
</ul>
</td>
</tr>
<tr>
<td valign="top"><code>tls_key_file</code></td>
<td valign="top">yes</td>
<td valign="top">The path to the private key to use for
HTTPS. The path is relative to the directory of the
configuration file.</td>
</tr>
<tr>
<td valign="top"><code>tls_cert_file</code></td>
<td valign="top">yes</td>
<td valign="top">The path to the certificate to use for
HTTPS. The path is relative to the directory of the
configuration file.</td>
</tr>
<tr>
<td valign="top"><code>client_ca_file</code></td>
<td valign="top">no</td>
<td valign="top">The root certificate to trust for
mutual authentication. If provided, any clients connecting to
Notary signer need a client certificate signed by
this root. If not provided, mutual authentication is not
required. The path is relative to the directory of the
configuration file.</td>
</tr>
</table>
## storage section (required)
This is used to store encrypted private keys. We only support MySQL or an
in-memory store, currently.
Example:
```json
"storage": {
"backend": "mysql",
"db_url": "user:pass@tcp(notarymysql:3306)/databasename?parseTime=true",
"default_alias": "passwordalias1"
}
```
<table>
<tr>
<th>Parameter</th>
<th>Required</th>
<th>Description</th>
</tr>
<tr>
<td valign="top"><code>backend</code></td>
<td valign="top">yes</td>
<td valign="top">Must be <code>"mysql"</code> or <code>"memory"</code>.
If <code>"memory"</code> is selected, the <code>db_url</code>
is ignored.</td>
</tr>
<tr>
<td valign="top"><code>db_url</code></td>
<td valign="top">yes if not <code>memory</code></td>
<td valign="top">The <a href="https://github.com/go-sql-driver/mysql">
the Data Source Name used to access the DB.</a>
(include <code>parseTime=true</code> as part of the DSN)</td>
</tr>
<tr>
<td valign="top"><code>default_alias</code></td>
<td valign="top">yes if not <code>memory</code></td>
<td valign="top">This parameter specifies the alias of the current
password used to encrypt the private keys in the DB. All new
private keys are encrypted using this password, which
must also be provided as the environment variable
<code>NOTARY_SIGNER_&lt;DEFAULT_ALIAS_VALUE&gt;</code>.
See the <a href="#environment-variables-required-if-using-mysql">environment variable</a>
section for more information.</td>
</tr>
</table>
## Environment variables (required if using MySQL)
Notary signer stores the private keys in encrypted form.
The alias of the passphrase used to encrypt the keys is also stored. In order
to encrypt the keys for storage and decrypt the keys for signing, the
passphrase must be passed in as an environment variable.
For example, the configuration above specifies the default password alias to be
`passwordalias1`.
If this configuration is used, then you must:
```bash
export NOTARY_SIGNER_PASSWORDALIAS1=mypassword
```
so that that Notary signer knows to encrypt all keys with the passphrase
`mypassword`, and to decrypt any private key stored with password alias
`passwordalias1` with the passphrase `mypassword`.
Older passwords may also be provided as environment variables.
Let's say that you wanted to change the password that is used to create new
keys (rotating the passphrase and re-encrypting all the private keys is not
supported yet).
You could change the config to look like:
```json
"storage": {
"backend": "mysql",
"db_url": "user:pass@tcp(notarymysql:3306)/databasename?parseTime=true",
"default_alias": "passwordalias2"
}
```
Then you can set:
```bash
export NOTARY_SIGNER_PASSWORDALIAS1=mypassword
export NOTARY_SIGNER_PASSWORDALIAS2=mynewfancypassword
```
That way, all new keys are encrypted and decrypted using the passphrase
`mynewfancypassword`, but old keys that were encrypted using the passphrase
`mypassword` can still be decrypted.
The environment variables for the older passwords are optional, but Notary
Signer cannot decrypt older keys if they are not provided, and
attempts to sign data using those keys fail.
## Related information
* [Notary Server Configuration File](server-config.md)
* [Configuration sections common to the Notary server and signer](common-configs.md)

BIN
notary/resources/ncc_docker_notary_audit_2015_07_31.pdf
View File

Binary file not shown.

135
notary/resources/opensslCertGen.sh
View File

@ -1,135 +0,0 @@
#!/usr/bin/env bash
# Script to be used for generating testing certs only - for a production system,
# a public CA or an internal CA should be used
CLIENT_USAGE=$(cat <<EOL
Generate a self-signed client cert and key to be used in mutual TLS.
${0} client [-o <output file prefix>]
Example:
${0} client -o clienttls
EOL
)
SERVER_USAGE=$(cat <<EOL
Generate a self-signed cert key and certificate.
${0} server -n <common name> [-o <output file prefix>]
[-r <root key if do not want it self-signed>]
[-a <subjectAltName>] [-a <subjectAltName>] ...
Example:
${0} server -o servertls -n notary-server -a DNS:notaryserver \
-a DNS:notary_server -a IP:127.0.0.1
EOL
)
if [[ -z "${1}" ]]; then
printf "${CLIENT_USAGE}\n\n${SERVER_USAGE}\n\n"
exit 1
fi
OPENSSLCNF=
for path in /etc/openssl/openssl.cnf /etc/ssl/openssl.cnf /usr/local/etc/openssl/openssl.cnf; do
if [[ -e ${path} ]]; then
OPENSSLCNF=${path}
fi
done
if [[ -z ${OPENSSLCNF} ]]; then
printf "Could not find openssl.cnf"
exit 1
fi
if [[ "${1}" == "client" ]]; then
# Generate client keys - ensure that these keys are NOT CA's, otherwise
# any client that is compromised can sign any number of other client
# certs.
OUT="clienttls"
while getopts "o:" opt "${@:2}"; do
case "${opt}" in
o)
OUT="${OPTARG}"
;;
*)
printf "${CLIENT_USAGE}"
exit 1
;;
esac
done
openssl genrsa -out "${OUT}.key" 4096
openssl req -new -key "${OUT}.key" -out "${OUT}.csr" \
-subj '/C=US/ST=CA/L=San Francisco/O=Docker/CN=Notary Testing Client Auth'
cat > "${OUT}.cnf" <<EOL
[ssl_client]
basicConstraints = critical,CA:FALSE
nsCertType = critical, client
keyUsage = critical, digitalSignature, nonRepudiation
extendedKeyUsage = critical, clientAuth
authorityKeyIdentifier=keyid,issuer
EOL
openssl x509 -req -days 3650 -in "${OUT}.csr" -signkey "${OUT}.key" \
-out "${OUT}.crt" -extfile "${OUT}.cnf" -extensions ssl_client
rm "${OUT}.cnf" "${OUT}.csr"
fi
if [[ "${1}" == "server" ]]; then
# Create a server certificate
OUT="servertls"
COMMONNAME=
SAN=
while getopts ":o:n:a:" opt "${@:2}"; do
case "${opt}" in
o)
OUT="${OPTARG}"
;;
n)
COMMONNAME="${OPTARG}"
;;
a)
SAN="${SAN} ${OPTARG}"
;;
*)
printf "${SERVER_USAGE}\n\n"
exit 1
;;
esac
done
if [[ -z "${COMMONNAME}" ]]; then
printf "Please provide a common name/domain for the cert."
printf "\n\n${SERVER_USAGE}\n\n"
exit 1
fi
PPRINT_DOMAINS="${COMMONNAME}$(printf ", %s" "${SAN[@]}")"
printf "Generating server certificate for domains: ${PPRINT_DOMAINS}\n\n"
# see https://www.openssl.org/docs/manmaster/apps/x509v3_config.html for
# more information on extensions
cat "${OPENSSLCNF}" > "${OUT}.cnf"
cat >> "${OUT}.cnf" <<EOL
[ v3_req ]
basicConstraints = critical,CA:FALSE
nsCertType = critical, server
keyUsage = critical, digitalSignature, nonRepudiation
extendedKeyUsage = critical, serverAuth
authorityKeyIdentifier=keyid,issuer
EOL
if [[ -n "${SAN}" ]]; then
printf "subjectAltName=$(echo ${SAN[@]} | tr ' ' ,)" >> "${OUT}.cnf"
fi
openssl genrsa -out "${OUT}.key" 4096
openssl req -new -nodes -key "${OUT}.key" -out "${OUT}.csr" \
-subj "/C=US/ST=CA/L=San Francisco/O=Docker/CN=${COMMONNAME}" \
-config "${OUT}.cnf" -extensions "v3_req"
openssl x509 -req -days 3650 -in "${OUT}.csr" -signkey "${OUT}.key" \
-out "${OUT}.crt" -extensions v3_req -extfile "${OUT}.cnf"
fi

BIN
notary/resources/tuf_update_flow.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 50 KiB

260
notary/running_a_service.md
View File

@ -1,260 +0,0 @@
---
description: Run your own notary service to host arbitrary content signing.
keywords: docker, notary, notary-server, notary server, notary-signer, notary signer
title: Run a Notary service
---
This document is for anyone who wants to run their own Notary
service (such as those who want to use Notary with a
private Docker registry). Running a Notary service requires that you are already
familiar with using [Docker Engine](/engine/userguide/)
and [Docker Compose](/compose/).
## Run a service for testing or development
The quickest way to spin up a full Notary service for testing and development
purposes is to use the Docker compose file in the
[Notary project](https://github.com/docker/notary).
```console
$ git clone https://github.com/theupdateframework/notary.git
$ cd notary
$ docker-compose up
```
This builds the development Notary server and Notary signer images, and
start up containers for the Notary server, Notary signer, and the MySQL
database that both of them share. The MySQL data is stored in a volume.
Notary server and Notary signer communicate over mutually authenticated TLS
(using the self-signed testing certs in the repository), and Notary server
listens for HTTPS traffic on port 4443.
By default, this development Notary server container runs with the testing
self-signed TLS certificates. Before you can successfully connect to
it, you must use the root CA file in `fixtures/root-ca.crt`.
For example, to connect using OpenSSL:
```console
$ openssl s_client -connect <docker host>:4443 -CAfile fixtures/root-ca.crt -no_ssl3 -no_ssl2
```
To connect using the Notary Client CLI, see [Getting Started](getting_started.md).
The version of the Notary server and signer
needs to be greater than or equal to that of the Notary Client CLI to ensure feature compatibility.
For instance, if you use Notary Client CLI 0.2, the server and signer each need
to be at least version 0.2 as well.
The self-signed certificate's subject name and subject alternative names are
`notary-server`, `notaryserver`, and `localhost`, so if your Docker host is not
on `localhost` (for example if you are using Docker Machine),
update your hosts file such that the name `notary-server` is associated with
the IP address of your Docker host.
## Advanced configuration options
Both the Notary server and the Notary signer take
[JSON configuration files](reference/index.md). Pre-built images, such as
the [development images above](running_a_service.md#run-a-service-for-testing-or-development)
provide these configuration files for you with some sane defaults.
However, for running in production, or if you just want to change those defaults
on your development service, you probably want to change those defaults.
### Running with different command line arguments
You can override the `docker run` command for the image if you want to pass
different command line options. Both Notary server and Notary signer take
the following command line arguments:
- `-config=<config file>` - specify the path to the JSON configuration file.
- `-debug` - Passing this flag enables the debugging server on `localhost:8080`.
The debugging server provides
[pprof](https://golang.org/pkg/net/http/pprof) and
[expvar](ttps://golang.org/pkg/expvar/) endpoints.
(Remember, this is localhost with respect to the running container - this endpoint is not
exposed from the container).
This option can also be set in the configuration file.
- `-logf=<format>` - This flag sets the output format for the logs. Possible
formats are "json" and "logfmt".
This option cannot be set in the configuration file, since some log
messages are produced on startup before the configuration file has been
read.
### Specifying your own configuration files
You can run the images with your own configuration files entirely.
You just need to mount your configuration directory, and then pass the
path to that configuration file as an argument to the `docker run` command.
### Overriding configuration file parameters using environment variables
You can also override the parameters of the configuration by
setting environment variables of the form `NOTARY_SERVER_<var>` or
`NOTARY_SIGNER_<var>`.
`var` is the ALL-CAPS, `"_"`-delimited path of keys from the top level of the
configuration JSON.
For instance, if you wanted to override the storage URL of the Notary server
configuration:
```json
{
"storage": {
"backend": "mysql",
"db_url": "dockercondemo:dockercondemo@tcp(notary-mysql)/dockercondemo"
}
}
```
You would need to set the environment variable `NOTARY_SERVER_STORAGE_DB_URL`,
because the `db_url` is in the `storage` section of the Notary server
configuration JSON.
ou cannot override a key whose value is another map. For instance, setting
`NOTARY_SERVER_STORAGE='{"storage": {"backend": "memory"}}'` does not set
in-memory storage. It just fails to parse. You can only override keys whose
values are strings or numbers.
For example, let's say that you wanted to run a single Notary server instance:
- with your own TLS cert and keys
- with a local, in-memory signer service rather than using Notary signer
- using a local, in-memory TUF metadata store rather than using MySQL
- produce JSON-formatted logs
One way to do this would be:
1. Generate your own TLS certificate and key as `server.crt` and `server.key`,
and put them in the directory `/tmp/server-configdir`.
2. Write the following configuration file to `/tmp/server-configdir/config.json`:
```json
{
"server": {
"http_addr": ":4443",
"tls_key_file": "./server.key",
"tls_cert_file": "./server.crt"
},
"trust_service": {
"type": "remote",
"hostname": "notarysigner",
"port": "7899",
"tls_ca_file": "./root-ca.crt",
"key_algorithm": "ecdsa",
"tls_client_cert": "./notary-server.crt",
"tls_client_key": "./notary-server.key"
},
"storage": {
"backend": "mysql",
"db_url": "server@tcp(mysql:3306)/notaryserver?parseTime=True"
}
}
```
NWe include a remote trust service and a database storage
type to demonstrate how environment variables can override
configuration parameters.
3. Run the following command (assuming you've already built or pulled a Notary server docker image):
```console
$ docker run \
-p "4443:4443" \
-v /tmp/server-configdir:/etc/docker/notary-server/ \
-e NOTARY_SERVER_TRUST_SERVICE_TYPE=local \
-e NOTARY_SERVER_STORAGE_BACKEND=memory \
-e NOTARY_SERVER_LOGGING_LEVEL=debug \
notary_server \
-config=/etc/docker/notary-server/config.json \
-logf=json
{"level":"info","msg":"Version: 0.2, Git commit: 619f8cf","time":"2016-02-25T00:53:59Z"}
{"level":"info","msg":"Using local signing service, which requires ED25519. Ignoring all other trust_service parameters, including keyAlgorithm","time":"2016-02-25T00:53:59Z"}
{"level":"info","msg":"Using memory backend","time":"2016-02-25T00:53:59Z"}
{"level":"info","msg":"Starting Server","time":"2016-02-25T00:53:59Z"}
{"level":"info","msg":"Enabling TLS","time":"2016-02-25T00:53:59Z"}
{"level":"info","msg":"Starting on :4443","time":"2016-02-25T00:53:59Z"}
```
You can do the same using
[Docker Compose](/compose/) by setting volumes,
environment variables, and overriding the default command for the Notary server
containers in the Compose file.
## Recommendations for deploying in production
When moving from development to production there are a number of considerations
that must be made to ensure security and scalability.
### Certificates
The Notary repository includes sample certificates in the fixtures directory.
When you initialize a development service using the provided `docker-compose.yml`
file, these sample certificates are used to create a more production like
environment.
**You must acquire your own certificates to use in a production deployment.**
The sample private key files in the Notary repository are obviously public knowledge
and using them in a production deployment is highly insecure.
### Certificate directory
Notary is a user/client-based system, and it searches for certificates in the
user's home directory, at `~/.docker/trust`. To streamline using Notary from
the command line, create an alias that maps the user's `trust` directory to
the system's `ca-certificates` directory.
```console
$ alias notary="notary -s https://<dtr-url> -d ~/.docker/trust --tlscacert /usr/local/share/ca-certificates/<dtr-url>.crt"
```
### Databases
The server and signer each require a database. These should be separate databases
with different users. The users should be limited in their permissions. We recommend
giving the following MySQL (or equivalent) permissions to the users restricted to
only their own databases:
- Notary server database user: `SELECT, INSERT, UPDATE, DELETE`
- Notary signer database user: `SELECT, INSERT, DELETE`
### High Availability
To increase availability, you can run multiple instances
of both the server and signer applications. These can scale arbitrarily and
independently. The database can also scale independently but this is left as
an exercise for experienced DBAs and Operations teams. A typical deployment
looks like this:
![Notary server Deployment Diagram](https://cdn.rawgit.com/docker/notary/09f81717080f53276e6881ece57cbbbf91b8e2a7/docs/images/service-deployment.svg)
In the diagram, a load balancer routes external traffic to a cluster of Notary server
instances. These may make requests to Notary signer instances if either a) signing
is required, or b) key generation is required. The requests from a Notary server
to a Notary signer cluster are router via an internal load balancer.
Notary can be used with a CDN or other caching system. All GET requests for JSON
files may be cached indefinitely __except__ URLs matching:
- `*/root.json`
- `*/timestamp.json`
All other requests for JSON files include sha256 checksums of the file being requested
and are therefore immutable. Requests for JSON files make up the vast majority of
all notary requests. Requests for anything other than a GET of a JSON file should
not be cached.
## Related information
* [Notary service architecture](service_architecture.md)
* [Notary configuration files](reference/index.md)

373
notary/service_architecture.md
View File

@ -1,373 +0,0 @@
---
description: How the three requisite notary components interact
keywords: docker, notary, notary-client, docker content trust, content trust, notary-server, notary server, notary-signer, notary signer, notary architecture
title: Understand the Notary service architecture
---
On this page, you get an overview of the Notary service architecture.
## Brief overview of TUF keys and roles
This document assumes familiarity with
[The Update Framework](https://www.theupdateframework.com/){:target="_blank" rel="noopener" class="_"},
but here is a brief recap of the TUF roles and corresponding key hierarchy:
![TUF Key Hierarchy](https://cdn.rawgit.com/docker/notary/09f81717080f53276e6881ece57cbbbf91b8e2a7/docs/images/key-hierarchy.svg){:width="400px"}
- The root key is the root of all trust. It signs the
[root metadata file](https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L489){:target="_blank" rel="noopener" class="_"},
which lists the IDs of the root, targets, snapshot, and timestamp public keys.
Clients use these public keys to verify the signatures on all the metadata files
in the repository. This key is held by a collection owner, and should be kept offline
and safe, more so than any other key.
- The snapshot key signs the
[snapshot metadata file](https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L604){:target="_blank" rel="noopener" class="_"},
which enumerates the filenames, sizes, and hashes of the root,
targets, and delegation metadata files for the collection. This file is used to
verify the integrity of the other metadata files. The snapshot key is held by
either a collection owner/administrator, or held by the Notary service to facilitate
[signing by multiple collaborators via delegation roles](advanced_usage.md#working-with-delegation-roles).
- The timestamp key signs the
[timestamp metadata file](https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L827){:target="_blank" rel="noopener" class="_"},
which provides freshness guarantees for the collection by having the shortest expiry time of any particular
piece of metadata and by specifying the filename, size, and hash of the most recent
snapshot for the collection. It is used to verify the integrity of the snapshot
file. The timestamp key is held by the Notary service so the timestamp can be
automatically re-generated when it is requested from the server, rather than
require that a collection owner come online before each timestamp expiry.
- The targets key signs the
[targets metadata file](https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L678){:target="_blank" rel="noopener" class="_"},
which lists filenames in the collection, and their sizes and respective
[hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function){:target="_blank" rel="noopener" class="_"}.
This file is used to verify the integrity of some or all of the actual contents of the repository.
It is also used to
[delegate trust to other collaborators via delegation roles](advanced_usage.md#working-with-delegation-roles).
The targets key is held by the collection owner or administrator.
- Delegation keys sign
[delegation metadata files](https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L678){:target="_blank" rel="noopener" class="_"},
which lists filenames in the collection, and their sizes and respective
[hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function){:target="_blank" rel="noopener" class="_"}.
These files are used to verify the integrity of some or all of the actual contents of the repository.
They are also used to
delegate trust to other collaborators via lower level [delegation roles](advanced_usage.md#work-with-delegation-roles).
Delegation keys are held by anyone from the collection owner or administrator to
collection collaborators.
## Architecture and components
Notary clients pull metadata from one or more (remote) Notary services. Some
Notary clients push metadata to one or more Notary services.
A Notary service consists of a Notary server, which stores and updates the
signed
[TUF metadata files](https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L348){:target="_blank" rel="noopener" class="_"}
for multiple trusted collections in an associated database, and a Notary signer, which
stores private keys for and signs metadata for the Notary server. The following
diagram illustrates this architecture:
![Notary Service Architecture Diagram](/notary/images/service-architecture.svg)
Root, targets, and (sometimes) snapshot metadata are generated and signed by
clients, who upload the metadata to the Notary server. The server is
responsible for:
- ensuring that any uploaded metadata is valid, signed, and self-consistent
- generating the timestamp (and sometimes snapshot) metadata
- storing and serving to clients the latest valid metadata for any trusted collection
The Notary signer is responsible for:
- storing the private signing keys
[wrapped](https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-4.4){:target="_blank" rel="noopener" class="_"}
and
[encrypted](https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-4.8){:target="_blank" rel="noopener" class="_"}
using [Javascript Object Signing and Encryption](https://github.com/dvsekhvalnov/jose2go){:target="_blank" rel="noopener" class="_"}
in a database separate from the Notary server database
- performing signing operations with these keys whenever the Notary server requests
## Example client-server-signer interaction
The following diagram illustrates the interactions between the Notary client,
server, and signer:
![Notary Service Sequence Diagram](https://cdn.rawgit.com/docker/notary/27469f01fe244bdf70f34219616657b336724bc3/docs/images/metadata-sequence.svg)
1. Notary server optionally supports authentication from clients using
[JWT](https://jwt.io){:target="_blank" rel="noopener" class="_"} tokens. This requires an
authorization server that manages access controls, and a cert bundle from this
authorization server containing the public key it uses to sign tokens.
If token authentication is enabled on Notary server, then any connecting
client that does not have a token is redirected to the authorization
server.
See the docs for
[Docker Registry v2 authentication]( https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md)
for more information.
2. The client logs in to the authorization server via basic auth over HTTPS,
obtain a bearer token, and then present the token to Notary server on future
requests.
3. When clients uploads new metadata files, Notary server checks them against
any previous versions for conflicts, and verifies the signatures, checksums,
and validity of the uploaded metadata.
4. Once all the uploaded metadata has been validated, Notary server
generates the timestamp (and maybe snapshot) metadata. It sends this
generated metadata to the Notary signer to be signed.
5. Notary signer retrieves the necessary encrypted private keys from its database
if available, decrypts the keys, and uses them to sign the metadata. If
successful, it sends the signatures back to Notary server.
6. Notary server is the source of truth for the state of a trusted collection of
data, storing both client-uploaded and server-generated metadata in the TUF
database. The generated timestamp and snapshot metadata certify that the
metadata files the client uploaded are the most recent for that trusted collection.
Finally, Notary server notifies the client that their upload was successful.
7. The client can now immediately download the latest metadata from the server,
using the still-valid bearer token to connect. Notary server only needs to
obtain the metadata from the database, since none of the metadata has expired.
In the case that the timestamp has expired, Notary server would go through
the entire sequence where it generates a new timestamp, request Notary signer
for a signature, stores the newly signed timestamp in the database. It then
sends this new timestamp, along with the rest of the stored metadata, to the
requesting client.
## Threat model
Both the server and the signer are potential attack vectors against all users
of the Notary service. Client keys are also a potential attack vector, but
not necessarily against all collections at a time. This section
discusses how our architecture is designed to deal with compromises.
### Notary server compromise
In the event of a Notary server compromise, an attacker would have direct access to
the metadata stored in the database as well as access to the credentials
used to communicate with Notary signer, and therefore, access to arbitrary signing
operations with any key the Signer holds.
- **Denial of Service** - An attacker could reject client requests and corrupt
or delete metadata from the database, thus preventing clients from the ability
to download or upload metadata.
- **Malicious Content** - An attacker can create, store, and serve arbitrary
metadata content for one or more trusted collections. However, the attacker
has no access to any client-side keys, such as root, targets, and potentially
the snapshot keys for the existing trusted collections.
A client can only be tricked into downloading and trusting the malicious
content for these trusted collections if it has never seen the trusted
collections and does not have any form of pinned trust.
If a client has previously interacted with any trusted collection or has its
trust pinned to a specific certificate for the collections, the client
immediately detects that the content is malicious and doesn't trust any root,
targets, or (maybe) snapshot metadata for these collections.
- **Rollback, Freeze, Mix and Match** - The attacker can request that
the Notary signer sign any arbitrary timestamp (and maybe snapshot) metadata
they want. Attackers can launch a freeze attack, and, depending on whether
the snapshot key is available, a mix-and-match attack up to the expiration
of the targets file.
Clients both with and without pinned trust would be vulnerable to these
attacks, so long as the attacker ensures that the version number of their
malicious metadata is higher than the version number of the most recent
good metadata that any client may have.
> **Note**: the timestamp and snapshot keys cannot be compromised in a server-only
> compromise, so a key rotation would not be necessary. Once the Server
> compromise is mitigated, an attacker cannot generate valid timestamp or
> snapshot metadata and serve them on a malicious mirror, for example.
### Notary signer compromise
In the event of a Notary signer compromise, an attacker would have access to
all the (timestamp and snapshot) private keys stored in a database.
If the keys are stored in an HSM, they would have the ability to sign arbitrary
content with, and to delete, the keys in the HSM, but not to exfiltrate the
private material.
- **Denial of Service** - An attacker could reject all Notary server requests
and corrupt or delete keys from the database (or even delete keys from an
HSM), and thus prevent Notary servers from signing generated
timestamps or snapshots.
- **Key Compromise** - If the Notary signer uses a database as its backend,
an attacker can exfiltrate all the (timestamp and snapshot) private material.
The capabilities of an attacker are the same as of a Notary server
compromise in terms of signing arbitrary metadata, with the important detail
that in this particular case key rotations are necessary to recover from
the attack.
### Notary client keys and credentials compromise
The security of keys held and administered by users depends on measures taken by
the users. If the Notary Client CLI was used to create them, then they are password
protected and the Notary CLI does not provide options to export them in
plaintext.
It is up to the user to choose an appropriate password, and to protect their key
from offline brute-force attacks.
The severity of the compromise of a trust collection owner/administrator's
decrypted key depends on the type and combination of keys compromised. For
example, were the snapshot and targets key both compromised, or just the targets
key?
#### Possible attacks given the credentials compromised:
##### Decrypted Delegation Key, only
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Delegation key | no | no | no |
##### Decrypted Delegation Key + Notary Service write-capable credentials
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Delegation key | limited, maybe* | limited, maybe* | limited, maybe* |
If the Notary Service holds the snapshot key and the attacker has Notary Service
write credentials, then they have effective access to the snapshot and timestamp
keys because the server generates and signs the snapshot and timestamp for them.
An attacker can add malicious content, remove legitimate content from a collection, and
mix up the targets in a collection, but only within the particular delegation
roles that the key can sign for. Depending on the restrictions on that role,
they may be restricted in what type of content they can modify. They may also
add or remove the capabilities of other delegation keys below it on the key hierarchy
For example, if `DelegationKey2` in the above key hierarchy is compromised, the
compromised key could
only modify the capabilities of `DelegationKey4` and `DelegationKey5`.
##### Decrypted Delegation Key + Decrypted Snapshot Key, only
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Delegation key, Snapshot key | no | no | no |
The attacker does not have access to the timestamp key, which is always held by the Notary
Service, and cannot set up a malicious mirror.
##### Decrypted Delegation Key + Decrypted Snapshot Key + Notary Service write-capable credentials
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Delegation key, Snapshot key | limited | limited | limited |
The Notary Service always holds the timestamp key. If the attacker has Notary Service
write credentials, then they have effective access to the timestamp key because the server
generates and signs the timestamp for them.
An attacker can add malicious content, remove legitimate content from a collection, and
mix up the targets in a collection, but only within the particular delegation
roles that the key can sign for. Depending on the restrictions on that role,
they may be restricted in what type of content they can modify. A key may also
add or remove the capabilities of other delegation keys below it on the key hierarchy
For example, if `DelegationKey2` in the above key hierarchy is compromised, it can
only modify the capabilities of `DelegationKey4` and `DelegationKey5`.
##### Decrypted Targets Key, only
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Targets key | no | no | no |
##### Decrypted Targets Key + Notary Service write-capable credentials
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Targets key | maybe* | maybe* | limited, maybe* |
If the Notary Service holds the snapshot key and the attacker has Notary Service
write credentials, then they have effective access to the snapshot and timestamp
keys because the server generates and signs the snapshot and timestamp for them.
An attacker can add any malicious content, remove any legitimate content from a
collection, and mix up the targets in a collection. They may also add or remove
the capabilities of any top level delegation key or role, such as `Delegation1`,
`Delegation2`, and `Delegation3` in the key hierarchy diagram. If they remove
the roles entirely, they break the trust chain to the lower delegation roles,
such as `Delegation4` or `Delegation5`.
##### Decrypted Targets Key + Decrypted Snapshot Key, only
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Targets key, Snapshot key | no | no | no |
The attacker does not have access to the timestamp key, which is always held by the Notary
Service, and cannot set up a malicious mirror.
##### Decrypted Targets Key + Decrypted Snapshot Key + Notary Service write-capable credentials
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| Targets key, Snapshot key | yes | yes | limited |
The Notary Service always holds the timestamp key. If the attacker has Notary Service
write credentials, then they have effective access to the timestamp key because the server
generates and signs the timestamp for them.
An attacker can add any malicious content, remove any legitimate content from a
collection, and mix up the targets in a collection. They may also add or remove
the capabilities of any top level delegation key or role, for example, `Delegation1`,
`Delegation2`, and `Delegation3` in the key hierarchy diagram. If they remove
the roles entirely, they'd break the trust chain to the lower delegation roles,
such as `Delegation4` or `Delegation5`.
##### Decrypted Root Key + none or any combination of decrypted keys, only
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| All keys | yes | yes | yes |
No other keys are needed, since the attacker can just any rotate or all of them to ones that they
generate. With these keys, they can set up a mirror to serve malicious data - any malicious data
at all, given that they have access to all the keys.
##### Decrypted Root Key + none or any combination of decrypted keys + Notary Service write-capable credentials
| Keys compromised | Malicious Content | Rollback, Freeze, Mix and Match | Denial of Service |
|------------------|-------------------|---------------------------------|-------------------|
| All keys | yes | yes | yes |
If the Notary Service holds the snapshot key and the attacker has Notary Service
write credentials, then they don't even need to rotate the snapshot and timestamp
keys because the server generates and signs the snapshot and timestamp for them.
#### Mitigations
If a root key compromise is detected, the root key holder should contact
whomever runs the notary service to manually reverse any malicious changes to
the repository, and immediately rotate the root key. This creates a fork
of the repository history, and thus break existing clients who have downloaded
any of the malicious changes.
If a targets key compromise is detected, the root key holder
must rotate the compromised key and push a clean set of targets using the new key.
If a delegations key compromise is detected, a higher level key
holder must rotate the compromised key, and push a clean set of targets using the new key.
If a Notary Service credential compromise is detected, the credentials should be
changed immediately.
## Related information
* [Run a Notary service](running_a_service.md)
* [Notary configuration files](reference/index.md)