[User Story] notation inspect signatures

[SteveLasker]

As a user, I want to inspect signatures so that I can make a more informed decision to trust the signer and make it easy to start trusting them.

Notary v2 does not support Trust On First Use (TOFU), and only trusts artifacts that have been configured with trusted keys, which means users need a way to find the public key to place within their trust store.

Scenario:

A user found a signed image in a registry they wish to use. The image may have been promoted to a private registry, decoupling the original location.
How do they find and download the public key to configure their trust policy?
The signature(s) provide the identity(s) of the entity(s) that signed the artifact. How does the user discover the info about the signers?

Proposal

A proposed API: notation inspect registry.wabbit-networks.io/net-monitor:v1 would extract information about the signing key, such as the location of the company that signed it, enabling the user to locate the public root key.

The user could then download the public key from the location and configure their trust policy.

The model here is not TOFU, rather a discoverability model for the user to make an educated decision about the identity of an artifact, and decide if they choose to trust them.

Implementation items to complete

• CLI spec for notation inspect notation#213
• Implementing inspect command notation#219

[iamsamirzon]

So is the proposal to keep the public key in the repository/registry? But how does the consumer of the image know which is the original repository where the image publisher has kept the public key? I ask this because an image ( along with its signature) can move from registry tor registry, and the final registry may not be the one where the image was originally signed

[priteshbandi]

Isn't this proposal a variation of TOFU, consumer decides trust based on some property configured in the artifact.
Also, I have a similar question as that of Samir's How will a consumer knows that the key inside the repository/registry belongs to a specific publisher?

[gokarnm]

Addressing the scenario

A user found a signed image in a registry they wish to use.
How do they find and download the public key to configure their trust policy? 

The current trust policy requires users to configure a trust store containing trusted (root) certificates, and an optional trusted identity (X.509 certificate subject). Users don't specify raw public keys anywhere, we avoid this for signing certificate as this is key pinning which causes issues on key rotation.

Your proposal is a form of TOFU, that allows a pattern for end user to query the root key associated with the untrusted artifact, and use it to set trust policy. There may be intent that there is an intermediate step where user independently verifies if the root key is trusted or not, but this will be frequently bypassed, as users typically take the path of least resistance.

How does the workflow you propose protect users if a malicious actor is able to sign an artifact with their own keys (not stolen keys) and publish to a compromised registry?

For RC1 external documentation and publishing certificates on a publisher controlled website (https), and configuring trust store out of band before you consume images are the ways to address this. Plugin vendors can also install certificates in the Notation trust store.

Post RC1, we can look into default trust stores that ship with Notation, and the criteria for being included in the default trust store.

[SteveLasker]

So is the proposal to keep the public key in the repository/registry?

It's been a discussion, but I think that kinda defeats the two-key/2fa effort, and don't believe this is the right security model.

But how does the consumer of the image know which is the original repository where the image publisher has kept the public key? ..can move from registry tor registry, and the final registry may not be the one where the image was originally signed

Yup, this is core to the problem.

Isn't this proposal a variation of TOFU, consumer decides trust based on some property configured in the artifact.
Also, I have a similar question as that of Samir's How will a consumer knows that the key inside the repository/registry belongs to a specific publisher?

If we step back and have a client that has zero trust of any certs, where do they start to configure their store?
Should they trust any signed artifact? We've agreed no.
Now, they've been asked to support the net-monitor:v1 image that's been placed in a development registry by a development team. How do they know if they should trust it? Where is enough information about the image to decide if they should trust it?

The discussion here is how would someone discover who signed the net-monitor:v1 image, and how do they do research for the identity and make a decision to trust, or not.

It's a classic balance of usability and security.
If we make it too easy, it's not secure.
If we make it too hard, it's not used.

The notation trust store policy assumes someone is making the decision on whom to trust. The notation client should be capable of being locked down so that you can call notation verify, but not edit the trust store. That's what defeats TOFU, as there's no way to self-trust content.

The issue here is what information can be presented through an API similar to: notation inspect $ARTIFACT, that provides the user information to make that decision. The alternative of asking them to search the internet for docs, just makes it harder to use, not any more secure.

[SteveLasker]

I've updated the title and description to clarify the scenario a bit more.

[toddysm]

Usability is important here. Finding the signing keys has been user-unfriendly experience for a long time (PGP is a good example). Imagine every time you go to a website, and it tells you: "you need to find the public certificate to decrypt my traffic and to paste it here and then we can exchange traffic" but it doesn't tell you where this cert is. From experience point of view, we should target simplicity. Of course, as @SteveLasker says above, this may decrease the security if the cert is automatically downloaded and trusted. Nevertheless, discoverability should be built into the system.

Knowing who signed the artifact, where to obtain the verification key and its root CA should be part of the signature and this should travel from registry to registry.

[ianjmcm]

I have a similar perspective with regards to discoverability of the public key to provide the consuming party choice to trust. Platform providers historically provide a trust list that is the basis of all that should be trusted on their platform, and this is great for the everyday layman user and a great baseline for folks that are more advanced (such as enterprises). Commonly I see in the Windows world, commercial consumers looking to expand or reduce their trust store (especially true with regards to app control stories these days), and they are demanding the flexibility while maintaining the same security controls over the trust policies that define these levels of trust. I believe we should support the discoverability and configurability folks will need and call on platform providers to publish baseline trust list for their platform(s) as applicable.

[SteveLasker]

I've added Balancing Security and Usability for reference

[dtzar]

This is a more specific enhancement ask for the inspect command, so transferring implementation to 238.

[yizha1]

As aligned in previous meeting, move this issue to RC-2 scope

[toddysm]

There is separate issue for key discovery filed here notaryproject/specifications#95 We should have a spec for the inspect command to make sure the functionality is agreed upon.

[iamsamirzon]

As a user of the signature, I will want Inspect command to display any other aspects encoded in the signature, such as (Common name of the signing identity, trust anchor, any metadata that the signer provided during signing). Essentially a human readable format of the signature.

[yizha1]

Closed as released in rc.2