From 5594292fe7d9572dc9a127d9c1f1c56eb3489316 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Fri, 26 Jun 2020 14:13:19 -0400 Subject: [PATCH 01/14] TAP13 draft --- README.md | 1 + tap13.md | 164 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 165 insertions(+) create mode 100644 tap13.md diff --git a/README.md b/README.md index a4dabef6..83412926 100644 --- a/README.md +++ b/README.md @@ -16,6 +16,7 @@ * [TAP 8: Key rotation and explicit self-revocation](tap8.md) * [TAP 11: Using POUFs for Interoperability](tap11.md) * [TAP 12: Improving keyid flexibility](tap12.md) +* [TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata](tap12.md) ## Rejected diff --git a/tap13.md b/tap13.md new file mode 100644 index 00000000..8c28d46d --- /dev/null +++ b/tap13.md @@ -0,0 +1,164 @@ +* TAP: 13 +* Title: User Selection of the Top-Level Target Files Through Mapping Metadata +* Version: 1 +* Last-Modified: 06-Jun-2020 +* Author: Justin Cappos, Joshua Lock, Marina Moore, Lukas Pühringer +* Status: Draft +* Content-Type: text/markdown +* Requires: TAP 4 +* Created: 29-May-2020 + +# Abstract + +This TAP discusses a means by which different users of the same repository +may elect to use different, repository-hosted, top-level targets metadata. This effectively +enables different namespaces to exist on a repository and also provides +additional resilience to attack in the case that the root keys on the +repository are compromised. + + + +# Motivation + + +In TUF, it is not possible for different users to have different namespaces on +the same repository. That is, if Alice and Bob both use repository X and ask +for package foo, they will both receive the same package. +This proposal enables clients to restrict the targets they consume to +filtered views of the repository. + +These different views could be defined by either different users on the +repository, made available by the repository administrator, or be created by +some other third party. One likely use is to have a repository where the signing +authority for namespaced collections of targets are delegated to more granular +roles, such as in the proposed PyPI Maximum Security Model where developers +sign for the targets produced by their projects. A client can curate a list of +trusted projects which is a subset of the targets on the repository by using +mapping metadata per [TAP 4](tap4.md) to only include roles they trust in their +targets metadata. One could imagine that other users (perhaps those at the +same organization) would also like to use the same curated list. These use +cases are all supported by this proposal. + +There are several reasons why it may be important to let Alice and Bob's view of +the repository differ. + +First, Alice and Bob may each curate different lists of packages that they +trust. For example, the security team at Alice's company has only blessed +specific packages and Alice wishes to install only those packages. Every other +user clearly should not be subject to those constraints. + +Second, Alice may be concerned that a full repository compromise may include +the root role. Since the root role in TUF indicates the top-level target's +role key, this compromise can enable the attacker full control of Alice's +namespace. Alice may want to require that the security team at her company +still be used to decide which packages to trust. + +Finally, in fact, Alice's company may have dictated that references to a +specific tag name should all (transparently) refer to a specific in-house +version, which may not match the result of +resolving foo using the repository's top-level targets metadata. +Instead foo should refer to the name that is resolved using Alice’s +company’s targets metadata file as the top-level targets metadata file. This may +also enable Alice to install software which is available on the repository +but would not be trusted by other users. + +Note that in all of the above cases, Alice and Bob still want to use the +repository as a means to coordinate and obtain new versions of targets +metadata. They however 1) want control of what packages would be installed +and 2) want to limit the damage caused by a root key compromise on the +repository. + +# Rationale + +We introduce this TAP because the alternative is slightly onerous. One could +technically achieve the first and second use cases (different curated lists of +packages and additional protection against a compromise of the repository’s +root key) by using delegations to multiple repositories. The way in which this +would work would be to have the security team at Alice's company run their +own repository and for Alice to use a mapping [TAP 4](tap4.md) that indicates +that both the security team and the original repository must be trusted for an +installation to happen. In this way, only software blessed by the security team +may be installed. + +However, this does not support the final use case above of transparently +referring to an in-house version. The reason is that +the original repository must also indicate that software is trustworthy, which it +would not in this case. This TAP allows the user to override (i.e., ignore) the +top-level targets metadata. The repository's separate namespace will not +match with Alice's in this case. + +# Specification + +In order to support this situation, we propose a change to the mapping +metadata to enable the name and key(s) for a targets metadata file to be specified. +This targets metadata file will be uploaded to the repository and will be used as though +it is the top-level targets metadata file by the client instead of the top-level targets +metadata file listed in the repository's root metadata. As is true in all TUF repositories, +all targets metadata files are listed in the snapshot file and benefit from the usual +rollback and similar protections provided. + +Note that both the name and the key MUST be specified. If the name +were permitted to be specified without the key, then the repository +would be trusted to serve the correct file, without any offline key attesting +to which keys indicate the targets role. + +As such, we add to the [Mechanisms that Assigns Targets to Repositories](https://github.com/theupdateframework/taps/blob/master/tap4.md#mechanism-that-assigns-targets-to-repositories) +support for a reference to the targets file in an identical way to the +root file's reference in the [TUF specification](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#4-document-formats). +However, additionally, the file name must be specified as this is no longer +targets.json. + +Note that the TUF specification's discussions about metadata storage, writing, +and retrieval are not changed by this TAP. The description about how to +(optionally) write consistent snapshots is not changed by this TAP. Consistent +snapshots already require versioned metadata to be available for all targets metadata +files. All targets metadata files (top-level and otherwise) are also stored in the +same METAPATH location listed in snapshot.json. + +The changes in the client application workflow are fairly minor from this +TAP. Steps 4.0 and 4.4.0 should refer to the specified target's metadata file instead +of the top-level targets metadata file. Additionally, instead of verifying the targets metadata +file using the key in the root metadata in step 4.0, verification must use the +keys listed in the mapping metadata. + +There likely also needs to be a clarity pass throughout to make this potential +use mode clearer in the specification. + +From an operational standpoint, a lost targets key for a delegated target could have been +remedied before by the repository but this no longer works. If the repository delegated to +a target from the top-level targets role, that file could be updated if Alice’s key changed or +was lost. However, as the repository’s root role is no longer trusted, any clients using this +TAP must take more care if it is operationally difficult to touch clients in the case of key +loss, perhaps first using a targets role with a threshold of offline keys before delegating to +a developer’s key. TAP 8 also provides support for cases where the key need to be rotated +or changed and the key is still accessible to the developer. + + +# Security Analysis + +Our overall belief is that this is a security positive change to TUF. +The added complexity from this change is fairly small. The mapping metadata +itself already exists in TUF and this TAP merely makes a small addition to +parameterize the top-level targets role. We feel that implementation errors +with adding this TAP are unlikely to occur. However, the ability to better +control trust should help users to better secure important operational use +cases. We are also unaware of plausible scenarios where this feature would +lead to insecurity due to abuse or misconfiguration. Hence our belief is that +this TAP will be a security positive change. + +# Backwards Compatibility + +This TAP does not require clients that do not support this TAP to update. +Hence, all existing clients may continue to update. As the mapping metadata +is controlled on the client device, this will need to be updated along with the +client implementation. The repository metadata does not change in any way. + +# Augmented Reference Implementation + +[TODO: Point to a branch containing implementation of TAP 13.] + +# Copyright + +This document has been placed in the public domain. + + From eec007675724762330a2594c35b4be3aa43c6a3f Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Fri, 26 Jun 2020 14:17:34 -0400 Subject: [PATCH 02/14] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 83412926..274e9076 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ * [TAP 8: Key rotation and explicit self-revocation](tap8.md) * [TAP 11: Using POUFs for Interoperability](tap11.md) * [TAP 12: Improving keyid flexibility](tap12.md) -* [TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata](tap12.md) +* [TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata](tap13.md) ## Rejected From 8c0ef12011ca6f6abace15c4cae1f0795e256fc3 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Mon, 29 Jun 2020 13:44:47 -0400 Subject: [PATCH 03/14] Update tap13.md Co-authored-by: lukpueh --- tap13.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tap13.md b/tap13.md index 8c28d46d..86cd3421 100644 --- a/tap13.md +++ b/tap13.md @@ -31,7 +31,7 @@ These different views could be defined by either different users on the repository, made available by the repository administrator, or be created by some other third party. One likely use is to have a repository where the signing authority for namespaced collections of targets are delegated to more granular -roles, such as in the proposed PyPI Maximum Security Model where developers +roles, such as in the proposed [PyPI Maximum Security Model](https://www.python.org/dev/peps/pep-0480/) where developers sign for the targets produced by their projects. A client can curate a list of trusted projects which is a subset of the targets on the repository by using mapping metadata per [TAP 4](tap4.md) to only include roles they trust in their @@ -161,4 +161,3 @@ client implementation. The repository metadata does not change in any way. This document has been placed in the public domain. - From cc692d47a80315fd210d75d4430fedcb13cb98ce Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Mon, 29 Jun 2020 14:16:39 -0400 Subject: [PATCH 04/14] Update tap13.md --- tap13.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tap13.md b/tap13.md index 86cd3421..0c89c16c 100644 --- a/tap13.md +++ b/tap13.md @@ -128,8 +128,10 @@ From an operational standpoint, a lost targets key for a delegated target could remedied before by the repository but this no longer works. If the repository delegated to a target from the top-level targets role, that file could be updated if Alice’s key changed or was lost. However, as the repository’s root role is no longer trusted, any clients using this -TAP must take more care if it is operationally difficult to touch clients in the case of key -loss, perhaps first using a targets role with a threshold of offline keys before delegating to +TAP must take more care because the root metadata may not be used to revoke trust in +the targets key. Thus, a user should take into account the operational difficultly to touch +clients in the case of key loss for the top level targets file. If it is operationally difficult to +touch the clients, then the client may perhaps use a threshold of offline keys before delegating to a developer’s key. TAP 8 also provides support for cases where the key need to be rotated or changed and the key is still accessible to the developer. @@ -160,4 +162,3 @@ client implementation. The repository metadata does not change in any way. # Copyright This document has been placed in the public domain. - From 3c90fa2a3e6feac9c4d0ee3601d0059c8784d674 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Mon, 29 Jun 2020 14:19:29 -0400 Subject: [PATCH 05/14] Update tap13.md --- tap13.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tap13.md b/tap13.md index 0c89c16c..b939ab78 100644 --- a/tap13.md +++ b/tap13.md @@ -145,8 +145,9 @@ parameterize the top-level targets role. We feel that implementation errors with adding this TAP are unlikely to occur. However, the ability to better control trust should help users to better secure important operational use cases. We are also unaware of plausible scenarios where this feature would -lead to insecurity due to abuse or misconfiguration. Hence our belief is that -this TAP will be a security positive change. +lead to insecurity due to abuse or misconfiguration except the inability to +have the root role rotate the targets key. However, selectively removing this +capability from the root role is the purpose of this TAP. # Backwards Compatibility From 0de3dc8f5420184f726cbb4e33f1ef8d3f684de1 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Tue, 30 Jun 2020 11:05:56 -0400 Subject: [PATCH 06/14] Update tap13.md Co-authored-by: lukpueh --- tap13.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tap13.md b/tap13.md index b939ab78..51580a73 100644 --- a/tap13.md +++ b/tap13.md @@ -127,7 +127,7 @@ use mode clearer in the specification. From an operational standpoint, a lost targets key for a delegated target could have been remedied before by the repository but this no longer works. If the repository delegated to a target from the top-level targets role, that file could be updated if Alice’s key changed or -was lost. However, as the repository’s root role is no longer trusted, any clients using this +was lost. However, as the repository’s root role is no longer trusted to provide top-level targets keys, any clients using this TAP must take more care because the root metadata may not be used to revoke trust in the targets key. Thus, a user should take into account the operational difficultly to touch clients in the case of key loss for the top level targets file. If it is operationally difficult to From 64302b05945d28b6ba717176b79185c7131d36a0 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Tue, 30 Jun 2020 11:06:15 -0400 Subject: [PATCH 07/14] Update tap13.md Co-authored-by: lukpueh --- tap13.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tap13.md b/tap13.md index 51580a73..a579cc6b 100644 --- a/tap13.md +++ b/tap13.md @@ -132,7 +132,7 @@ TAP must take more care because the root metadata may not be used to revoke trus the targets key. Thus, a user should take into account the operational difficultly to touch clients in the case of key loss for the top level targets file. If it is operationally difficult to touch the clients, then the client may perhaps use a threshold of offline keys before delegating to -a developer’s key. TAP 8 also provides support for cases where the key need to be rotated +a developer’s key. [TAP 8](tap8.md) also provides support for cases where the key need to be rotated or changed and the key is still accessible to the developer. From eaaddf700e5e36335cb5c343ec42b3c058bc4ecf Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 18 May 2021 11:20:55 -0700 Subject: [PATCH 08/14] TAP 13: Add attack description to motivation Explain at the beginning of the motivation section why namespaces are needed in TUF to protect clients from malicious repositories. Signed-off-by: Marina Moore --- tap13.md | 101 ++++++++++++++++++++++++++++++------------------------- 1 file changed, 56 insertions(+), 45 deletions(-) diff --git a/tap13.md b/tap13.md index a579cc6b..d1fe0575 100644 --- a/tap13.md +++ b/tap13.md @@ -13,18 +13,29 @@ This TAP discusses a means by which different users of the same repository may elect to use different, repository-hosted, top-level targets metadata. This effectively enables different namespaces to exist on a repository and also provides -additional resilience to attack in the case that the root keys on the +additional resilience to attack in the case that the root keys on the repository are compromised. # Motivation - -In TUF, it is not possible for different users to have different namespaces on -the same repository. That is, if Alice and Bob both use repository X and ask -for package foo, they will both receive the same package. -This proposal enables clients to restrict the targets they consume to +In TUF, the root and targets roles on the repository are responsible for +delegating the correct key to each delegated targets. A third party that controls +a delegated targets role gives their keys to the delegating role on the +repository, then has to trust that the repository will correctly list the +trusted keys for their role. This means that a malicious repository maintainer +can overwrite delegated keys in order to sign arbitrary software. + +In the case of some public repositories, the repository is considered an untrusted +distribution mechanism, and should not be trusted with this key management. +For these repositories, the owner of a delegated targets role needs a mechanism +to ensure that their users can pin keys. + +To allow for these untrusted repositories, we propose adding namespaces to TUF +repositories. That is, if Alice and Bob both use repository X and ask +for package foo, they may get different results based on their trusted namespaces. +This proposal enables clients to restrict the targets they consume to filtered views of the repository. These different views could be defined by either different users on the @@ -34,36 +45,36 @@ authority for namespaced collections of targets are delegated to more granular roles, such as in the proposed [PyPI Maximum Security Model](https://www.python.org/dev/peps/pep-0480/) where developers sign for the targets produced by their projects. A client can curate a list of trusted projects which is a subset of the targets on the repository by using -mapping metadata per [TAP 4](tap4.md) to only include roles they trust in their +mapping metadata similar to [TAP 4](tap4.md) to only include roles they trust in their targets metadata. One could imagine that other users (perhaps those at the -same organization) would also like to use the same curated list. These use +same organization) would also like to use the same curated list. These use cases are all supported by this proposal. -There are several reasons why it may be important to let Alice and Bob's view of +There are several reasons why it may be important to let Alice and Bob's view of the repository differ. -First, Alice and Bob may each curate different lists of packages that they +First, Alice and Bob may each curate different lists of packages that they trust. For example, the security team at Alice's company has only blessed specific packages and Alice wishes to install only those packages. Every other user clearly should not be subject to those constraints. Second, Alice may be concerned that a full repository compromise may include the root role. Since the root role in TUF indicates the top-level target's -role key, this compromise can enable the attacker full control of Alice's +role key, this compromise can enable the attacker full control of Alice's namespace. Alice may want to require that the security team at her company still be used to decide which packages to trust. Finally, in fact, Alice's company may have dictated that references to a specific tag name should all (transparently) refer to a specific in-house -version, which may not match the result of +version, which may not match the result of resolving foo using the repository's top-level targets metadata. -Instead foo should refer to the name that is resolved using Alice’s -company’s targets metadata file as the top-level targets metadata file. This may -also enable Alice to install software which is available on the repository +Instead foo should refer to the name that is resolved using Alice’s +company’s targets metadata file as the top-level targets metadata file. This may +also enable Alice to install software which is available on the repository but would not be trusted by other users. -Note that in all of the above cases, Alice and Bob still want to use the -repository as a means to coordinate and obtain new versions of targets +Note that in all of the above cases, Alice and Bob still want to use the +repository as a means to coordinate and obtain new versions of targets metadata. They however 1) want control of what packages would be installed and 2) want to limit the damage caused by a root key compromise on the repository. @@ -73,33 +84,33 @@ repository. We introduce this TAP because the alternative is slightly onerous. One could technically achieve the first and second use cases (different curated lists of packages and additional protection against a compromise of the repository’s -root key) by using delegations to multiple repositories. The way in which this -would work would be to have the security team at Alice's company run their -own repository and for Alice to use a mapping [TAP 4](tap4.md) that indicates -that both the security team and the original repository must be trusted for an -installation to happen. In this way, only software blessed by the security team +root key) by using delegations to multiple repositories. The way in which this +would work would be to have the security team at Alice's company run their +own repository and for Alice to use a mapping [TAP 4](tap4.md) that indicates +that both the security team and the original repository must be trusted for an +installation to happen. In this way, only software blessed by the security team may be installed. -However, this does not support the final use case above of transparently +However, this does not support the final use case above of transparently referring to an in-house version. The reason is that the original repository must also indicate that software is trustworthy, which it -would not in this case. This TAP allows the user to override (i.e., ignore) the +would not in this case. This TAP allows the user to override (i.e., ignore) the top-level targets metadata. The repository's separate namespace will not match with Alice's in this case. # Specification -In order to support this situation, we propose a change to the mapping +In order to support this situation, we propose a change to the mapping metadata to enable the name and key(s) for a targets metadata file to be specified. This targets metadata file will be uploaded to the repository and will be used as though -it is the top-level targets metadata file by the client instead of the top-level targets -metadata file listed in the repository's root metadata. As is true in all TUF repositories, -all targets metadata files are listed in the snapshot file and benefit from the usual +it is the top-level targets metadata file by the client instead of the top-level targets +metadata file listed in the repository's root metadata. As is true in all TUF repositories, +all targets metadata files are listed in the snapshot file and benefit from the usual rollback and similar protections provided. Note that both the name and the key MUST be specified. If the name were permitted to be specified without the key, then the repository -would be trusted to serve the correct file, without any offline key attesting +would be trusted to serve the correct file, without any offline key attesting to which keys indicate the targets role. As such, we add to the [Mechanisms that Assigns Targets to Repositories](https://github.com/theupdateframework/taps/blob/master/tap4.md#mechanism-that-assigns-targets-to-repositories) @@ -109,29 +120,29 @@ However, additionally, the file name must be specified as this is no longer targets.json. Note that the TUF specification's discussions about metadata storage, writing, -and retrieval are not changed by this TAP. The description about how to +and retrieval are not changed by this TAP. The description about how to (optionally) write consistent snapshots is not changed by this TAP. Consistent -snapshots already require versioned metadata to be available for all targets metadata -files. All targets metadata files (top-level and otherwise) are also stored in the +snapshots already require versioned metadata to be available for all targets metadata +files. All targets metadata files (top-level and otherwise) are also stored in the same METAPATH location listed in snapshot.json. The changes in the client application workflow are fairly minor from this -TAP. Steps 4.0 and 4.4.0 should refer to the specified target's metadata file instead +TAP. Steps 4.0 and 4.4.0 should refer to the specified target's metadata file instead of the top-level targets metadata file. Additionally, instead of verifying the targets metadata -file using the key in the root metadata in step 4.0, verification must use the +file using the key in the root metadata in step 4.0, verification must use the keys listed in the mapping metadata. There likely also needs to be a clarity pass throughout to make this potential use mode clearer in the specification. -From an operational standpoint, a lost targets key for a delegated target could have been -remedied before by the repository but this no longer works. If the repository delegated to -a target from the top-level targets role, that file could be updated if Alice’s key changed or +From an operational standpoint, a lost targets key for a delegated target could have been +remedied before by the repository but this no longer works. If the repository delegated to +a target from the top-level targets role, that file could be updated if Alice’s key changed or was lost. However, as the repository’s root role is no longer trusted to provide top-level targets keys, any clients using this -TAP must take more care because the root metadata may not be used to revoke trust in -the targets key. Thus, a user should take into account the operational difficultly to touch +TAP must take more care because the root metadata may not be used to revoke trust in +the targets key. Thus, a user should take into account the operational difficultly to touch clients in the case of key loss for the top level targets file. If it is operationally difficult to -touch the clients, then the client may perhaps use a threshold of offline keys before delegating to +touch the clients, then the client may perhaps use a threshold of offline keys before delegating to a developer’s key. [TAP 8](tap8.md) also provides support for cases where the key need to be rotated or changed and the key is still accessible to the developer. @@ -139,11 +150,11 @@ or changed and the key is still accessible to the developer. # Security Analysis Our overall belief is that this is a security positive change to TUF. -The added complexity from this change is fairly small. The mapping metadata -itself already exists in TUF and this TAP merely makes a small addition to -parameterize the top-level targets role. We feel that implementation errors -with adding this TAP are unlikely to occur. However, the ability to better -control trust should help users to better secure important operational use +The added complexity from this change is fairly small. The mapping metadata +itself already exists in TUF and this TAP merely makes a small addition to +parameterize the top-level targets role. We feel that implementation errors +with adding this TAP are unlikely to occur. However, the ability to better +control trust should help users to better secure important operational use cases. We are also unaware of plausible scenarios where this feature would lead to insecurity due to abuse or misconfiguration except the inability to have the root role rotate the targets key. However, selectively removing this From 7b3e67a0b2eb2838d2394dd2aff54e4a08fb07ec Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 20 May 2021 09:41:10 -0700 Subject: [PATCH 09/14] TAP 13: Update motivation Signed-off-by: Marina Moore --- tap13.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/tap13.md b/tap13.md index d1fe0575..5e6cf69b 100644 --- a/tap13.md +++ b/tap13.md @@ -20,17 +20,20 @@ repository are compromised. # Motivation -In TUF, the root and targets roles on the repository are responsible for -delegating the correct key to each delegated targets. A third party that controls +Currently if a user trusts a TUF repository, a compromise of the targets role +for that repository enables an attacker to install arbitrary malicious software. +The targets role on the repository is responsible for delegating to the correct +key for each delegated targets, and so may also arbitrarily replace these keys. +A third party that controls a delegated targets role gives their keys to the delegating role on the repository, then has to trust that the repository will correctly list the -trusted keys for their role. This means that a malicious repository maintainer -can overwrite delegated keys in order to sign arbitrary software. +trusted keys for their role. In some cases, the user may wish to reduce trust +in the repository by maintaining control of key distribution. -In the case of some public repositories, the repository is considered an untrusted -distribution mechanism, and should not be trusted with this key management. +For users of some public repositories, the repository is considered an untrusted +distribution mechanism, and should not be trusted with this key distribution. For these repositories, the owner of a delegated targets role needs a mechanism -to ensure that their users can pin keys. +to ensure that their users can define and pin keys. To allow for these untrusted repositories, we propose adding namespaces to TUF repositories. That is, if Alice and Bob both use repository X and ask @@ -46,7 +49,7 @@ roles, such as in the proposed [PyPI Maximum Security Model](https://www.python. sign for the targets produced by their projects. A client can curate a list of trusted projects which is a subset of the targets on the repository by using mapping metadata similar to [TAP 4](tap4.md) to only include roles they trust in their -targets metadata. One could imagine that other users (perhaps those at the +targets metadata. One could imagine that other users (perhaps those at the same organization) would also like to use the same curated list. These use cases are all supported by this proposal. From ac6bce2acd78281889b1cb40e311945d895b917e Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 25 May 2021 10:46:29 -0700 Subject: [PATCH 10/14] TAP 13: Add use cases to motivation Add use cases for both using the claimed role in PyPI as the top-level namespace, and a container registry using a curated list of packages Signed-off-by: Marina Moore --- tap13.md | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/tap13.md b/tap13.md index 5e6cf69b..6156e514 100644 --- a/tap13.md +++ b/tap13.md @@ -43,15 +43,20 @@ filtered views of the repository. These different views could be defined by either different users on the repository, made available by the repository administrator, or be created by -some other third party. One likely use is to have a repository where the signing -authority for namespaced collections of targets are delegated to more granular -roles, such as in the proposed [PyPI Maximum Security Model](https://www.python.org/dev/peps/pep-0480/) where developers -sign for the targets produced by their projects. A client can curate a list of -trusted projects which is a subset of the targets on the repository by using -mapping metadata similar to [TAP 4](tap4.md) to only include roles they trust in their -targets metadata. One could imagine that other users (perhaps those at the -same organization) would also like to use the same curated list. These use -cases are all supported by this proposal. +some other third party. Some likely uses include: +* Limiting packages on a repository to those that have been signed by their +developer. For example, in the proposed [PyPI Maximum Security Model](https://www.python.org/dev/peps/pep-0480/), +packages that are only signed by the repository are listed under the 'unclaimed' +targets role, while packages that are signed by developers are delegated +from the 'claimed' targets role. A user may wish to restrict packages to those +that have been end-to-end signed, and so only use packages delegated from +'claimed'. +* Curating a list of verified packages. A company may curate a subset of +packages available on a container registry that have been validated for use +by their customers. This curated list may include packages that the company +signs, as well as trusted third-party dependencies. They may then +distribute this curated list to users, who want to ensure that only +validated packages are installed. There are several reasons why it may be important to let Alice and Bob's view of the repository differ. @@ -67,8 +72,8 @@ role key, this compromise can enable the attacker full control of Alice's namespace. Alice may want to require that the security team at her company still be used to decide which packages to trust. -Finally, in fact, Alice's company may have dictated that references to a -specific tag name should all (transparently) refer to a specific in-house +Finally, in fact, Alice's company may have dictated that references to +'foo' should all (transparently) refer to a specific in-house version, which may not match the result of resolving foo using the repository's top-level targets metadata. Instead foo should refer to the name that is resolved using Alice’s From 7cca85a83a63db19b1c3eed2aaa86d389e95a672 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Tue, 2 Nov 2021 20:57:00 +0800 Subject: [PATCH 11/14] Update tap13.md Co-authored-by: Joshua Lock --- tap13.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tap13.md b/tap13.md index 6156e514..2ba22749 100644 --- a/tap13.md +++ b/tap13.md @@ -11,8 +11,9 @@ # Abstract This TAP discusses a means by which different users of the same repository -may elect to use different, repository-hosted, top-level targets metadata. This effectively -enables different namespaces to exist on a repository and also provides +may elect to use different, repository-hosted, top-level targets metadata. This +effectively enables different namespaces to exist on a repository which a client +may choose to trust -- or not -- in a granular fashion, and also provides additional resilience to attack in the case that the root keys on the repository are compromised. From 116842a891172f30b5e4b92ad4f2e5e7bb620269 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Tue, 2 Nov 2021 20:57:29 +0800 Subject: [PATCH 12/14] Update tap13.md Co-authored-by: Joshua Lock --- tap13.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tap13.md b/tap13.md index 2ba22749..1aec9ee2 100644 --- a/tap13.md +++ b/tap13.md @@ -1,7 +1,7 @@ * TAP: 13 * Title: User Selection of the Top-Level Target Files Through Mapping Metadata * Version: 1 -* Last-Modified: 06-Jun-2020 +* Last-Modified: 02-Nov-2021 * Author: Justin Cappos, Joshua Lock, Marina Moore, Lukas Pühringer * Status: Draft * Content-Type: text/markdown From a31e53531a363581ad11f0977efaf273bbc3889d Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Tue, 2 Nov 2021 20:58:57 +0800 Subject: [PATCH 13/14] Update tap13.md Co-authored-by: Joshua Lock --- tap13.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tap13.md b/tap13.md index 1aec9ee2..4e798a55 100644 --- a/tap13.md +++ b/tap13.md @@ -45,14 +45,15 @@ filtered views of the repository. These different views could be defined by either different users on the repository, made available by the repository administrator, or be created by some other third party. Some likely uses include: -* Limiting packages on a repository to those that have been signed by their -developer. For example, in the proposed [PyPI Maximum Security Model](https://www.python.org/dev/peps/pep-0480/), +* **Limiting packages on a repository to those that have been signed by their +developer.** For example, in the proposed +[PyPI Maximum Security Model](https://www.python.org/dev/peps/pep-0480/), packages that are only signed by the repository are listed under the 'unclaimed' targets role, while packages that are signed by developers are delegated from the 'claimed' targets role. A user may wish to restrict packages to those that have been end-to-end signed, and so only use packages delegated from 'claimed'. -* Curating a list of verified packages. A company may curate a subset of +* **Curating a list of verified packages.** A company may curate a subset of packages available on a container registry that have been validated for use by their customers. This curated list may include packages that the company signs, as well as trusted third-party dependencies. They may then From 6d480abfc9e0c34b24bd80c7e5dc9802b0bb9f9b Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Tue, 2 Nov 2021 20:59:32 +0800 Subject: [PATCH 14/14] Update tap13.md Co-authored-by: Joshua Lock --- tap13.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tap13.md b/tap13.md index 4e798a55..1ca6cb5f 100644 --- a/tap13.md +++ b/tap13.md @@ -36,11 +36,12 @@ distribution mechanism, and should not be trusted with this key distribution. For these repositories, the owner of a delegated targets role needs a mechanism to ensure that their users can define and pin keys. -To allow for these untrusted repositories, we propose adding namespaces to TUF -repositories. That is, if Alice and Bob both use repository X and ask -for package foo, they may get different results based on their trusted namespaces. -This proposal enables clients to restrict the targets they consume to -filtered views of the repository. +To allow for safer use of these untrusted repositories, we propose adding +namespaces to TUF repositories which enable explicit trust decisions. In This +mode, if Alice and Bob both use repository X and ask for package foo, they may +get different results based on their trusted namespaces. +In summary; this proposal enables clients to restrict the targets they consume +to filtered views of the repository. These different views could be defined by either different users on the repository, made available by the repository administrator, or be created by