Relate TUF design to Notary v2 goals #41
Conversation
Add a section to the design document describing which goals TUF addresses to make it clear why this design suggests using TUF to achieve the goals of the Notary v2 effort. Signed-off-by: Marina Moore <mnm678@gmail.com>
There was a problem hiding this comment.
Thanks @mnm678 for the updates. I've added comments that reflect the original notes, as the addition of the requirements & goals are helpful.
| other goals of the Notary v2 effort, including interacting with OCI compliant | ||
| registries, support for private registries, and allowing for movement between | ||
| repositories or registries. | ||
|
|
There was a problem hiding this comment.
Ephemeral clients: Ephemeral clients cannot rely on existing state for security properties. They receive some minimal initialization data, so root private keys may be included in this configuration
Is acquiring the private related to build/sign scenarios, where a signature is created? Or, is there an implication the private key is required for signature validation on ephemeral clients for deployment validation?
Using Multiple Signatures
Users may want to verify that multiple parties have signed an image (per scenario #6 in the requirements). This may be to ensure that multiple teams have verified it (for example security and development teams), or that it has been approved by both the originator and an external company. Our design supports this use case through the use of multi-role delegations.
There seems to be a design point where the signatures are somehow aggregated through delegations. In our example, the wabbit-networks signature, docker-hub and acme-rockets signatures must travel across the registries, with no correlation with each other. They must be independent to align with the immutability aspect of registries, where each piece of content is independent from another. This is the basic model how registries can scale. It's also a basic premise of consuming public content best practices, where the data is copied, with no need to connect to, or even knowledge of the source.
Intermixing of content
As registry operators, we have contractual obligations to have no knowledge of content stored, or any aggregation of any assemblage of the content. Customers can double encrypt their data, with their own key. Some customers require us to exclude their content from anonymized data analytics. And, these are the customers that want the most security. Any validation of a signature must be solely within the scope of their data.
Timestamp verification for air-gapped environments
If that is not possible, the client can keep track of the last timestamp they verified, and ensure that the new timestamp is more recent. This provides a weaker guarantee than ensuring that the time is current, but it allows a longer delay in receiving metadata. These mitigations weaken some of the security guarantees of TUF, but this can be partly mitigated by having the transferring party (the party that gives the metadata to the offline device) perform TUF verification before passing the metadata to the non-connected device.
Having the client keep track of state is in conflict with the ephemeral client requirement. And, we're again talking about the most secure customers will use ephemeral clients, and want the most secure solution in their air-gapped environments.
Using multiple registries
An image may be moved between registries. To do so, the image index, and it’s associated targets metadata (unchanged) can be directly copied. ... The registry’s snapshot metadata will need to update to include the new targets metadata.
This sounds like we're not actually copying signatures, rather we're suggesting the content is resigned, with some knowledge of the source. The scenarios call out for signatures to be copied, as they are. The wabbit-networks signature must be capable of moving through docker-hub into acme-rockets, then into the acme-rockets air-gapped environment. If they want to verify against the wabbit-networks key, the docker-hub key, or one of the many acme-rockets environmental keys, the registry should be a simple transport, and provide integrity on the packaging and transference. If I ship a package from Seattle to Israel, there are many points along the way. I can place a seal on the package, and I want to assure the seal is still intact when it arrives. Having it resigned along the way implies that I have some trust in every carrier that touched the package. I actually don't want to know, or shouldn't care who touched the package, as long as I can verify the integrity of the package is intact.
Updating fully qualified references to artifacts
The initial signature should be fully intact. Including what registry it originated from. No change to the content, or the wraper. This is the integrity check.
Hiding images from other users
This section implies Coke & Pepsi content can be aggregated in some way, even at some anonymized leve is not permitted.
It's great to see the requirements get added and covered. The concerns over immutability, and how much updating of content must be maintained is of great concern.
Consider we might etched all the immutable content pushed to a registry in glass (Project Silica). The basic premise of TUF suggests a continual service runs to continually update snapshot and timestamps of all data. The vast majority of registry content is immutable. Following best tagging practices, even the tags should be unique, with the important exception of stable tags. And, we do need a solution for tag signing/locking. However, I'd suggest we should be focusing on a solution that doesn't require all data must be continually updated to assure it's still valid. It's a non-scalable solution. If the computers stop processing the data, because the data was etched in glass, put in a mountain, revived years later, is that data considered invalid?
General comment:
Notary v2 targets all content in a registry, including signign of images, the SBoMs of the image, Helm charts, WASM and anything else someone wants to store in a registry. Can you please do a search/replace for image/artifact?
There was a problem hiding this comment.
Thanks @mnm678 for the updates. I've added comments that reflect the original notes, as the addition of the requirements & goals are helpful.
| @@ -4,6 +4,36 @@ Based on discussions with the Notary v2 community over the past few months, we d | |||
|
|
|||
| This design will be used in conjunction with the OCI artifact work done by others in the Notary v2 community to ensure compliance with the OCI specification and integration with existing registries. | |||
|
|
|||
| ## Alignment with Notary v2 project goals | |||
|
|
|||
| The use of TUF in Notary v2 is part of an effort to address the [goals](https://github.com/notaryproject/requirements#goals) of the Notary v2 project. | |||
There was a problem hiding this comment.
Could we also address the requirements that have been agreed upon in key management?
Signed-off-by: Marina Moore <mnm678@gmail.com>
Signed-off-by: Marina Moore <mnm678@gmail.com>
|
@SteveLasker Thanks for the review! I added some clarifications inline to address many of your comments.
In this case, what would a registry do if they want to maintain this original signature as well as re-sign it? Should they re-sign using the original fully qualified reference? I can see two possible options here, in one the signature is copied and the original signer is the primary party trusted to sign the image. In this case any additional signatures would have to match the original name so they could have an exact match. In the other, the artifact is being copied into a private registry and the copier is the party trusted to sign it. In this case, it may be desirable to sign the image using the fully qualified reference in the new registry. There may also be an in-between option that allows only the last part of the name to match, but this raises questions about the scope of namespaces.
Users who need to download an image today have different security requirements than users who want to download an image from a mountain years later. Users today need a way to ensure that the signature they are verifying was signed by a key that was valid today, and not compromised or expired. This is vital to any mechanism that prioritizes key revocation. Users years from now have the benefit of hindsight to avoid compromised packages, and so can ignore timestamps when verifying metadata. I would argue that it is more important to ensure that users today are downloading secure software than it is to ensure that future users don’t have to override a timestamp check when using legacy software. |
Signed-off-by: Marina Moore <mnm678@gmail.com>
|
I'm going to close this in favor of a discussion of goals on the tuf-notary repository. |
Based on discussion in the last meeting, I added a section to clarify why the TUF design is being proposed that puts on paper some of what has previously been discussed in meetings about the use of TUF in Notary v2.