profile
viewpoint

cncf/sig-security 314

😎CNCF Special Interest Group on Security -- secure access, policy control, privacy, auditing, explainability and more!

in-toto/in-toto 258

in-toto is a framework to protect supply chain integrity.

EdgeNet-project/edgenet 9

Kubernetes adapted for the network edge

cmatthew/Lind-misc 3

Misc files for the Lind project

detectivelyw/lind_paper_atc17 1

Repo for Lind paper camera-ready version for USENIX ATC '17

detectivelyw/lind_paper_nsdi17 1

Lind paper for NSDI'17

detectivelyw/lind_paper_usenix16 1

Repo for Lind Paper Usenix Security 2016

ebrynne/ViewPoints 1

ViewPoints!

JustinCappos/dockersecretspaper 1

Paper draft describing Docker Secrets

push eventsecure-systems-lab/ssl-site

Lois Anne DeLong

commit sha a8fd8ac8e357346ed0de790330e1bc0c5af56d1b

adding jonathan

view details

Lois Anne DeLong

commit sha a5fdabf6e085f20d73e2f1180edb0c2993163232

Adding Jonathan plus people changes--added Jonathan, changed titles for Santiago and Dan, moved Santiago and Dan to alumni, moved Aditya to Ph.D. group Added publication listings for Sebastien, Lois, Marina, and Santiago

view details

Lois Anne DeLong

commit sha 8812df7aae30acb1aa51309279cd8ca1922b4696

More people changes Added Raghav Sai, Added students to project pages

view details

Lois Anne DeLong

commit sha c1bfdbbf2696a58a4ffe1c8265f841d6a3b22dd1

attempting to fix third commit I addressed some spacing oddities. Let's see is this fixes things

view details

Lois Anne DeLong

commit sha 26e1fd9cb15541c7b77c72dac7b8e3fd7a8e2705

Add photo-Raghav Sai

view details

Lois Anne DeLong

commit sha a0a6ce29dce590ead9020158927432ee5498eaac

added two publications

view details

Lois Anne DeLong

commit sha fd26be9a829e4b195751a44c84d7ab67bc5c8c46

attempting to fix last commit

view details

Lois Anne DeLong

commit sha 772bd8eeafe1ad47645acad8eed637d564b017b1

Added six press listings

view details

Justin Cappos

commit sha a516374ac2120ec7fb4959e5929dce37749c172f

Merge pull request #114 from secure-systems-lab/jhdalek55-patch-1 Updating titles, publications, and press

view details

push time in 2 days

PullRequestReviewEvent

Pull request review commenttheupdateframework/specification

Introduce a fixed notion of time for the duration of the update cycle

 repo](https://github.com/theupdateframework/specification/issues).   still be able to update again in the future. Errors raised during the update   process should not leave clients in an unrecoverable state. -  **0**. **Load the trusted root metadata file.** We assume that a good, trusted+  **0**. **Record the time at which the update began.** This update start time+  will be used when checking for freeze attacks.  Time is fixed at the+  beginning of the update workflow to prevent metadata expiring during an
  beginning of the update workflow to prevent metadata from expiring during an
joshuagl

comment created time in 6 days

Pull request review commenttheupdateframework/specification

Introduce a fixed notion of time for the duration of the update cycle

 repo](https://github.com/theupdateframework/specification/issues).   rollback attack.  On the next update cycle, begin at step 0 and version N of   the root metadata file. -  * **1.5**. Note that the expiration of the new (intermediate) root metadata-  file does not matter yet, because we will check for it in step 1.8.+  * **2.5**. Note that the expiration of the new (intermediate) root metadata+  file does not matter yet, because we will check for it in step 2.8. -  * **1.6**. **Set the trusted root metadata file** to the new root metadata+  * **2.6**. **Set the trusted root metadata file** to the new root metadata   file. -  * **1.7**. **Repeat steps 1.1 to 1.7**.+  * **2.7**. **Repeat steps 1.1 to 1.7**.++  * **2.8**. **Check for a freeze attack.**++    * **2.8.1** The latest known time should be lower than the update start+    time plus the update workflow maximum duration.  The update workflow+    maximum duration is set by the authors of the application using TUF and+    should typically be the same period at which the repository re-signs

Also, I wonder if we need to keep repeating the suggestion about setting the update workflow maximum duration. Might we be better off just saying this once?

joshuagl

comment created time in 6 days

Pull request review commenttheupdateframework/specification

Introduce a fixed notion of time for the duration of the update cycle

 repo](https://github.com/theupdateframework/specification/issues).   paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)   for more details. -  * **1.10**. **Set whether consistent snapshots are used as per the trusted+  * **2.10**. **Set whether consistent snapshots are used as per the trusted   root metadata file** (see Section 4.3). -**2**. **Download the timestamp metadata file**, up to X number of bytes+**3**. **Download the timestamp metadata file**, up to X number of bytes (because the size is unknown). The value for X is set by the authors of the application using TUF. For example, X may be tens of kilobytes. The filename used to download the timestamp metadata file is of the fixed form FILENAME.EXT (e.g., timestamp.json). The client MUST write the file to non-volatile storage as FILENAME.EXT. -  * **2.1**. **Check signatures.** The new timestamp metadata file must have+  * **3.1**. **Check signatures.** The new timestamp metadata file must have   been signed by a threshold of keys specified in the trusted root metadata   file.  If the new timestamp metadata file is not properly signed, discard it,   abort the update cycle, and report the signature failure. -  * **2.2**. **Check for a rollback attack.**+  * **3.2**. **Check for a rollback attack.** -    * **2.2.1**. The version number of the trusted timestamp metadata file, if+    * **3.2.1**. The version number of the trusted timestamp metadata file, if     any, must be less than or equal to the version number of the new timestamp     metadata file.  If the new timestamp metadata file is older than the     trusted timestamp metadata file, discard it, abort the update cycle, and     report the potential rollback attack. -    * **2.2.2**. The version number of the snapshot metadata file in the+    * **3.2.2**. The version number of the snapshot metadata file in the     trusted timestamp metadata file, if any, MUST be less than or equal to its     version number in the new timestamp metadata file.  If not, discard the new     timestamp metadadata file, abort the update cycle, and report the failure. -  * **2.3**. **Check for a freeze attack.** The latest known time should be-  lower than the expiration timestamp in the new timestamp metadata file.  If-  so, the new timestamp metadata file becomes the trusted timestamp metadata-  file.  If the new timestamp metadata file has expired, discard it, abort the-  update cycle, and report the potential freeze attack.+  * **3.3**. **Check for a freeze attack.**++    * **3.3.2** The latest known time should be lower than the update start
    * **3.3.1** The latest known time should be lower than the update start
joshuagl

comment created time in 7 days

Pull request review commenttheupdateframework/specification

Introduce a fixed notion of time for the duration of the update cycle

 repo](https://github.com/theupdateframework/specification/issues).   rollback attack.  On the next update cycle, begin at step 0 and version N of   the root metadata file. -  * **1.5**. Note that the expiration of the new (intermediate) root metadata-  file does not matter yet, because we will check for it in step 1.8.+  * **2.5**. Note that the expiration of the new (intermediate) root metadata+  file does not matter yet, because we will check for it in step 2.8. -  * **1.6**. **Set the trusted root metadata file** to the new root metadata+  * **2.6**. **Set the trusted root metadata file** to the new root metadata   file. -  * **1.7**. **Repeat steps 1.1 to 1.7**.+  * **2.7**. **Repeat steps 1.1 to 1.7**.++  * **2.8**. **Check for a freeze attack.**++    * **2.8.1** The latest known time should be lower than the update start+    time plus the update workflow maximum duration.  The update workflow+    maximum duration is set by the authors of the application using TUF and+    should typically be the same period at which the repository re-signs

Why is this suggested to be the period for re-signing metadata? Might that be much less frequently in some cases?

joshuagl

comment created time in 7 days

Pull request review commenttheupdateframework/specification

Introduce a fixed notion of time for the duration of the update cycle

 repo](https://github.com/theupdateframework/specification/issues).     The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD,"    "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be-   interpreted as described in RFC 2119.+   interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).

Would prefer to pull unrelated changes like this out so we can quickly merge them

joshuagl

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventtheupdateframework/theupdateframework.io

Trishank Karthik Kuppusamy

commit sha fffa597151eeda9d2e394848405f6d7e9c76aba4

add php-tuf Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Justin Cappos

commit sha 983ed7c5b0e247e6358dde13ac144fc74769f96e

Merge pull request #14 from trishankatdatadog/trishankatdatadog/php-tuf Add php-tuf to adoptions

view details

push time in 7 days

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 29812681644d08386bd3998c46c49363929b5922

few minor edits

view details

push time in 14 days

push eventuptane/uptane-standard

Jon Oster

commit sha a2646f8f8ead69f4467d47b3d1b6b7dc6c4b2abc

Clarify that partial verification is a minimum Signed-off-by: Jon Oster <jon.oster@here.com>

view details

Jon Oster

commit sha ccb4a07048541732e0aa0f06faf4d031e2348e12

PV language clarifications suggested by @jhdalek55 and @patrickvacek Co-authored-by: Lois Anne DeLong <lad278@nyu.edu>

view details

Jon Oster

commit sha 9be2c26a8898735c57764cd1e0012f9accf90189

Style: correct capitalization of Primary and Secondary ECUs Signed-off-by: Jon Oster <jon.oster@here.com>

view details

Jon Oster

commit sha 2fd3fb37a97baa97da9377e1bb7fbbc231af6658

Final wording updates Signed-off-by: Jon Oster <jon.oster@here.com>

view details

Jon Oster

commit sha 71feb870e9506bab8f2cbc582f57c645ad8afd73

Update uptane-standard.md Co-authored-by: Lois Anne DeLong <lad278@nyu.edu>

view details

Justin Cappos

commit sha 5b45ef5bb8887342dac8371a9297b05068714608

Merge pull request #165 from uptane/feat/partial-verification-clarification Clarify that partial verification is a minimum

view details

push time in 16 days

PR merged uptane/uptane-standard

Clarify that partial verification is a minimum

Add some language clarifying that PV ECUs can do more verification if desired, and that this can make the system more flexible.

+22 -16

14 comments

1 changed file

tkfu

pr closed time in 16 days

PullRequestReviewEvent

pull request commentcncf/sig-security

keycloak self assesment document

This is more a question for the chairs, etc., but how much prose cleanup do we want to do? Not that it's essential, but the grammar is a bit rough in some parts of the document...

On Tue, Sep 8, 2020 at 8:41 PM Brandon Lum notifications@github.com wrote:

@lumjjb commented on this pull request.

Thanks @bdaw https://github.com/bdaw ! Just a couple book keeping things:

  • Change images directory to docs for consistency across projects
  • Remove .DS_Store

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/cncf/sig-security/pull/417#pullrequestreview-484091307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD4C5OGGAUOQV7ZDCWTSEYQ6ZANCNFSM4Q6UAGDQ .

bdaw

comment created time in 23 days

pull request commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

On Tue, Sep 8, 2020 at 4:44 PM lukpueh notifications@github.com wrote:

@JustinCappos https://github.com/JustinCappos:

It would be up to whomever is creating the new role. Either the repo admin or the user whose account was compromised.

I agree. Plus coordination with the delegator is also required, because they need to add the new role to the delegating metadata, right?

Yes, for sure!

Note also, that this only really matters if the key was not compromised but somehow a fast forward account was done on the account. (Maybe a runaway script?)

Why does it only really matter if the key was not compromised?

If the key is compromised, you must change the key. There isn't an option to decide what to do and possibly just use the snapshot role to recover from the fast forward attack.

lukpueh

comment created time in 23 days

pull request commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

Would the onus be on the repository administrator to not reuse names? Or would we expect implementations to add some state-tracking for compromised names that can't be reused?

It would be up to whomever is creating the new role. Either the repo admin or the user whose account was compromised.

Note also, that this only really matters if the key was not compromised but somehow a fast forward account was done on the account. (Maybe a runaway script?)

lukpueh

comment created time in 23 days

pull request commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

I feel like I'm missing a little context here (apologies about this). Is this worried about primarily when the key changes but the role name stays the same?

I think the assumption when designing the ffwd defenses in Mercury was that these attacks will be rare (assuming we have a defense), so using the snapshot key is fine even if it is to recover from ffwd for a delegated role.

On Fri, Sep 4, 2020 at 11:46 PM Trishank Karthik Kuppusamy < notifications@github.com> wrote:

Thanks for documenting our discussion, @lukpueh https://github.com/lukpueh! I really do think choosing the simplest option and documenting the reasons why and its implications if the way to go. What do others think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/pull/86#issuecomment-687230905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD63Z53MTJG4RNPDK63SEEDUXANCNFSM4KNWXWQQ .

lukpueh

comment created time in a month

issue commentcncf/sig-security

[Suggestion] Establish Criteria and Boundaries for Security Assessment

You do make a valid point that letting the project being reviewed provide the material does have some potential for misuse, error, etc. Given the assessors are often unfamiliar with the project (and have full time jobs doing other things), we haven't really thought of a better way to address this issue. Do you have some thoughts?

I do also think we're likely just not being clear in the documentation. It isn't so much that the project owner performs the assessment, it's that they produce a document which we collectively later evolve into part of the assessment. The project's document is listed as the project's self assessment even though the security assessors contribute heavily to the document. We have two separate documents so that the project has editorial control of one document (the self-assessment) and the assessors have editorial control of another document. This helps to prevent either side from needing to fight over the content in a shared document because they each have their place to make a point.

chubirka

comment created time in a month

issue commentcncf/sig-security

[Suggestion] Perform hands-on security testing during security assessments

I am in general supportive of this. My only real concerns here are logistical. If we have the resources and can do this in a balanced way for all projects, then I'm 100% for it.

Any thoughts on how to achieve this?

Eriner

comment created time in a month

PullRequestReviewEvent

issue commentcncf/sig-security

[Suggestion] System for meeting times to make it friendly to other timezones

@JustinCappos now that you are in the chine timezone, can you workout a proposal for this -- one person that could be of help here is @hannibalhuang

From what I understand, this is mostly just setting up a meeting structure that mirrors the other SIG Security meeting, but which is at a more convenient time for participants in Asia. I'm not sure what you mean about working out a proposal.

I don't really know how to get the word out to the right folks. Thoughts on this?

lumjjb

comment created time in a month

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 5cef4efbb7b67ed2ac9342ebae54a22cb84154f2

PIX 11 Interview

view details

push time in a month

PullRequestReviewEvent
CommitCommentEvent

Pull request review commentcncf/sig-security

add more detail / clarification to conflict-of-interest guidelines

 # Security reviewer  ## Lead reviewer-The lead reviewer serves as the primary security assessment facilitator, often coordinating responses between the project and reviewers, ensuring communications are performed in a timely fashion as described in the [guide](./).  The lead reviewer also responsible for coordinating and recruiting additional reviewers as appropriate, reviewing and deliberating conflict of interest statements, and managing the documentation updates (self-assessment and final assessment) to the project's assessment folder.+The lead reviewer serves as the primary security assessment facilitator, often coordinating +responses between the project and reviewers, ensuring communications are performed in a timely +fashion as described in the [guide](./).  The lead reviewer also responsible for coordinating 

If I recall, I've always done COI (or asked the chairs to). I feel like pushing this to the ever-changing lead is a way to make this more uneven, which feels like the wrong thing to outsource especially since this is so little work...

ultrasaurus

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha b6c4eddb5be81397f511845720f90a84daa45c50

apostrophe error

view details

push time in a month

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 4a8c4cf1279c0c672580955291af77115b2b7792

TUF press

view details

push time in a month

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 0f50254963a16d0082298db1e60b6519e39c2a7b

press touch

view details

Justin Cappos

commit sha ee205a2c967e0d41e3d7222648bf640a00bcc410

Merge branch 'master' of github.com:secure-systems-lab/ssl-site

view details

push time in a month

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 8a798b93a6643fe38eb860b5fe0eff2b1eef57c3

Update Gemfile.lock Fixing dependency error. Was tested by IT folks.

view details

push time in a month

pull request commenttheupdateframework/tuf

Succinct hashed bin delegations

The main advantage of the new naming scheme for succinct hbd, i.e. "<DELEGATING_ROLE>.hbd-(0..2^BIT_LENGTH-1)", compared to the naming scheme of normal hbd, i.e. "<LOW>-<HIGH>", is that it adds the ability of different roles delegating to different hashed bins in one repository. Is there a use case for this? It seems more like a side-effect of the TAP than an original motivation. Also, if we didn't need that flexibility for normal hbd, why add it now for succinct hbd?

Yes, I believe the intention of the new naming scheme is to allow for different roles to create independent hashed bin delegations. I don't know that this ability has been requested by any existing implementer, but I can imagine a use case for registries as different uploaders to the same registry may each want to use succinct delegations. Does this seem like a likely use case? If not, we should probably stick with the existing naming scheme.

Yes, different parties need to be able to use this mechanism. I agree we must not omit the <DELEGATING_ROLE> from the name.

mnm678

comment created time in a month

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha b773be936afac5ac154f06a9000754922fbed81b

press touch

view details

push time in a month

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 52d04cb26915a1948bc7b80d96eedfe83dbb98dd

press add

view details

push time in a month

issue commentLind-Project/lind_project

Testing Bash Pipelines + Metrics

Please also disable the CPU monitor for repy (in nanny) if it isn't already done.

On Thu, Aug 13, 2020 at 5:38 PM Nicholas Renner notifications@github.com wrote:

I added a FlameGraph for the run with nanny now disabled as well here https://raw.githubusercontent.com/Lind-Project/lind_project/pipeline-test/graphs/catmbwc-nonanny.svg

Some great news, getting rid of Nanny basically got rid of the futex/sempost stacks that were very present before. Now we can clearly see some moderate sized chunks related to the deque implementation (collections.so, string_join, iter_next, extend).

On the other hand, there's this big chunk in the middle that gives us very little clue to what it is. The one clue is that the "fork" stack (on the right) is sitting above it, this leads me to believe it's NaCl related.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Lind-Project/lind_project/issues/56#issuecomment-673723291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD3JSCWNWNTQFNXGWMLSARMMJANCNFSM4L2S3IYQ .

rennergade

comment created time in 2 months

pull request commentSeattleTestbed/repy_v2

Adding security layer file

Sure, that branch was not merged.

Can you tell me more about what you are hoping to accomplish with the pull request? What is the security layer you are adding for?

On Sun, Aug 9, 2020 at 12:45 PM el3232 notifications@github.com wrote:

Yes, I made a mistake by committing the changes to SeattleTestbed rather than my forked repository. I'm just learning git and github and would love to talk about how to think about adding the correct files. It was my understanding that while RUNNABLE should be built anew each time, I wasn't sure how to correctly reflect that the security layer should be in the RUNNABLE folder (if it should).

How can we discuss? Also, my closing the pull request, have I already "removed" all the files I added?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SeattleTestbed/repy_v2/pull/141#issuecomment-671074464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODZHIOHPMJ7XU4B7AXTR73HCFANCNFSM4PZHZ5CQ .

el3232

comment created time in 2 months

push eventSeattleTestbed/repy_v2

Ashmita89

commit sha 0091e0acde465233b54222f8f31aaabebdd13d8a

Fix for #104

view details

Justin Cappos

commit sha 22df11f656548284647eda37ed152dfc45208e3b

Merge pull request #111 from Ashmita89/Fix-for-#104-help-string-log-file Fix for #104

view details

push time in 2 months

MemberEvent

issue commentcncf/sig-security

[Assessment] Keycloak

It's getting close. @ashutosh-narkar do you want to give a more detailed update?

bdaw

comment created time in 2 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha ac32cbddfcd0814102db893a8e2619c6f3631e2a

further cleanup

view details

push time in 2 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha c64feca89e843f11a6a34ff3a086c4b5c52298c2

press fix

view details

push time in 2 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha ac777860b5443cf2c14d110ed882f0107b96d8a2

Yahoo Finance

view details

push time in 2 months

issue commentuptane/uptane-standard

Incosistency Between Standard & Deployment Considerations

Uniqueness of ECU Private Key When discussing the ECU key in the Standard, Section 5.4.1 states this is a private key unique to the ECU.... On this topic, the Deployment Considerations states These keys should be unique to the ECU.

Proposal: Ensure consistency by allowing the ability for these keys to not be unique per ECU in the Standard.

Is there a reason we wouldn't just update the deployment considerations? The standard is messier to change and I as far as I know MUST is the right term here.

allen-cain

comment created time in 2 months

issue commentuptane/uptane-standard

Deployment Considerations Clarifications

Your proposal seems sensible. It also may be worth being even more vague about the timeframe.

A random thought, can we just say "at some point before the first update"?

allen-cain

comment created time in 2 months

MemberEvent

Pull request review commenttheupdateframework/taps

Added TAP for TUF Version Management

+* TAP:+* Title: Managing TUF Versions+* Version: 1+* Last-Modified: 20-July-2020+* Author: Marina Moore, Justin Cappos+* Status: Draft+* Content-Type: text/markdown+* Created: 19-December-2018++# Abstract++The TUF specification does not currently support changes+that are not backwards compatible. If a repository and a client are not using+the same version of the TUF specification, differences in metadata format may+mean that metadata cannot be safely and reliably verified. Any changes to the specification that+affect the metadata in this way are considered breaking changes. This TAP+addresses this clash of versions by allowing TUF+implementations to independently manage updates on clients and repositories.+This in turn ensures that TUF will continue functioning after breaking changes+are implemented.++To allow TUF implementers to adopt breaking changes without an interruption to+providing and verifying updates, this TAP requires two+changes: one to the way the TUF specification manages versions, and the other to+how TUF implementations perform updates. The former is accomplished by having this TAP require+that the specification use Semantic Versioning to separate breaking from+non-breaking changes. The latter is achieved by allowing both clients and+repositories to maintain sets of TUF metadata that follow different versions of the TUF specification+so that reliable updates can continue throughout the process of the specification+upgrade. To do so, repositories can generate metadata for multiple TUF+specification versions and maintain them in an accessible directory. In+addition, clients can include support for metadata from previous TUF versions.+To determine the version to use for an update, clients will select the most+recent specification version supported by both the client and the repository.+++# Motivation++Various TAPs, including TAPs 3 and 8, propose breaking changes.+Because these changes are not compatible with previous TUF versions,+current implementations that use the existing specification cannot access the+new features in these TAPs. By creating a way to deal with+breaking changes, TUF will be able to continuously provide secure+updates when breaking changes are made to the repository or+client. The use cases addressed in this TAP are listed below.++## Use case 1: A repository updates to a new TUF specification version++As new features become available in the TUF specification, repositories may wish+to upgrade to a new version. This could include adding TAPs with breaking+changes. When the repository upgrades, clients that use an older version of the+TUF specification will no longer be able to provide the security properties of TUF when+parsing metadata from the repository as the fields in the metadata may have changed.+However, repositories and clients may be managed by different people with+different interests who may not be able to coordinate the upgrade to a new TUF version.+To resolve this problem, clients will first need a way to determine whether+their version of TUF specification is compatible with the version used by the repository.+This is to ensure that clients always parse metadata according to the TUF version+that generated that metadata. Then, they will need some way to process updates+after this upgrade occurs on the repository to ensure reliable access to+updates, even if they are not able to upgrade immediately due to development+time or other constraints.++## Use case 2: A client updates to a new TUF specification version++Just as a repository may be upgraded, a TUF client may wish to upgrade to a new+TUF specification version to use new features. When the client implements an upgrade that+includes a breaking change, it cannot be sure that all repositories have also+upgraded to the new specification version. Therefore, after the client upgrades+they must ensure that any metadata downloaded from a repository is parsed using+a compatible TUF version. If the repository is using an older version, the client+should have some way to allow the update to proceed.++## Use case 3: A delegated targets role uses a different TUF specification version than the repository++A delegated role may make and sign metadata using a different version of the TUF+specification than the repository hosting the top-level roles. Delegated roles+and the top-level repository may be managed by people in different organizations+who are not able to coordinate upgrading to a new version of the TUF+specification. In this case, a client should be able to parse delegations that+generate metadata with a different TUF specification version than the repository.++## Use case 4: A client downloads metadata from multiple repositories++As described in TAP 4, TUF clients may download metadata from multiple+repositories. These repositories may not coordinate with each other, and so may+not upgrade to a new TUF specification version at the same time. A client should+be able to use multiple repositories that do not use the same version of TUF.+For example, a client may download metadata from one repository that uses TUF+version 1.0.0 and another repository that uses version 2.0.0.++## Use case 5: Backwards compatibility for existing clients++Existing TUF clients (written before this TAP is implemented) will still expect+to download and parse metadata. Before this TAP there was no method for determining compatibility+between a client and a repository, so existing TUF repositories should continue+to distribute metadata using their existing method to support existing clients. This+means that this mechanism for allowing backwards compatible updates must itself+be backwards compatible.++# Rationale++We propose this TAP because as TUF continues to evolve, the need for TUF clients+and repositories to upgrade their TUF metadata format will grow. This sets up the potential for clients+that are no longer able to perform updates because they cannot parse the+metadata generated by repositories, or for clients to install the wrong target files+due to changes in TUF. Both of these issues prevent clients from installing the+targets intended by repository managers, and in extreme cases could lead to critical security or+functionality problems. TUF clients and repositories need to be able to upgrade+to new versions without preventing secure and reliable access to software+updates.++In trying to create more flexible functionality between servers and clients when+it comes to dealing with different versions of the TUF specification, we identified two main+issues that need to be addressed. First, clients need to be able to determine+whether the TUF specification version they implement is compatible with the TUF+specification version of the metadata they receive. This ensures that clients parse+metadata according to the correct version to prevent errors from any changes to+the metadata in the new version. Second, clients need a way to use this+information to determine how to access metadata that is compatible with the+version of the TUF specification they implement.++To address the first issue, this TAP proposes standardizing the specification+version field to separate breaking changes from non-breaking changes and+ensure that the field can be compared across TUF clients and repositories.+Separating out non-breaking changes allows these backwards compatible changes to+happen at any time without affecting TUF's operation. Therefore, clients and+repositories can still coordinate after a non-breaking change occurs. One common+framework used to separate versions by type is Semantic Versioning. Semantic+Versioning is a versioning scheme popular across open source projects that+categorizes project versions by the scope and criticality of their+changes. Breaking changes in the specification would warrant a MAJOR version+number increase, while non-breaking changes would warrant only a MINOR version+number increase. In addition, Semantic Versioning has a standard way to format+version numbers so that they can be parsed and compared across implementations.++To address the second issue of accessing a compatible version, there are three+possible approaches. First, each repository could maintain sets of metadata that+implement multiple TUF versions while the clients only implement one TUF+specification version. In this case, TUF clients could not use metadata from+multiple repositories unless they all generate metadata that supports the same+TUF version (Use Case 4). In the second approach, each client could maintain+multiple versions that implement different versions of the TUF specification+while the repositories each generate metadata following a single TUF+specification version. In this case, if a repository upgrades to support a new+TUF version, clients will be unable to perform updates until support for the new+version is added to the client (Use Case 1). The third option is to implement+support for multiple TUF versions on both clients and repositories. This option+allows clients and repositories to be upgraded to support new versions of the+TUF specification independently and supports all use cases mentioned in this TAP.++This TAP adopts the third option, and describes procedures for both clients and+repositories to implement multiple TUF specification versions at the same time.+This requires both clients and+repositories to maintain multiple versions of the TUF spec, as well as changes+to the way repositories store metadata and clients parse this metadata.++For repositories, this means continuing support for old TUF versions for some+period of time after upgrading. This grace period gives existing clients that+implement old versions of the TUF specification time to implement support for a+new specification version. Repositories achieve this using a directory structure+with a directory for each supported TUF specification version. These directories+contain metadata that supports the given TUF specification version. Using these+directories, a client is able to choose the most recent metadata they support.+More details about this directory structure are contained in the [specification](#how-a-repository-updates).++On the client side, this TAP also requires maintenance of multiple versions that+support different TUF specification+versions to allow for communication with various repositories. To do so, it is+recommended that clients maintain functions that can be used to validate+metadata from previous TUF specification versions. These functions allow a+client to maintain old versions of the specification while still supporting the+most recent version.++The top-level TUF metadata (root, snapshot, timestamp, and top-level targets)+used to install an update should all implement the same TUF specification+version. A specification change may rely on more than one metadata file (for+example a change in the signing process would affect all metadata types), so+using the same specification version for top-level metadata allows for these+large changes to the specification. For information about how this relates to+url pinning and TAP 5, see [Special Cases](#tap-5). However, delegated targets metadata may not be+managed by the same parties as the top-level metadata. For this reason, this TAP+allows clients to use a different TUF specification version for delegated+targets by maintaining functions to parse metadata that conforms to different+specification versions. This compromise allows TUF specification changes to affect multiple+metadata files while allowing flexibility in how repositories and delegations+are managed.++For example, during the course of an update a client could use 4.0.0_parse_root,+4.0.0_parse_snapshot, 4.0.0_parse_timestamp, 4.0.0_parse_targets,+4.0.0_parse_delegation, and 3.0.0_parse_delegation.+++# Specification++As stated above, this TAP defines a variety of procedures to be added to the+update process on both clients and repositories. These changes include the way in which+version numbers are determined, the addition of new directories on repositories+and new metadata parsing functions on clients, and a new process for finding+compatible metadata.++For clarity, throughout this TAP *upgrading* refers to the process of moving+from one TUF specification version to another while *updating* refers to the+process of downloading and validating packages as specified by TUF. The rest of+this section details the changes to the TUF specification recommended by this+TAP.+++## Version Number Format++Using [Semantic Versioning](https://semver.org/), breaking changes will only+occur during a major release of the TUF specification (e.g. 1.x.x to 2.x.x). The+'spec_version' field of root metadata will follow this convention, with version+numbers in the format MAJOR.MINOR.PATCH. This is a standard format used in other+open source projects that makes the meaning of a TUF version number change+consistent and easily understood. The Backwards Compatibility section of a TAP+should be used to determine whether the TAP creates a breaking change. If the+change is not backwards compatible, such as those in TAPs 3 and 8, then it will+be part of a new major version of the TUF specification. Non backwards+compatible versions add features that change the way that TUF processes updates+and so clients and repositories need to use code that supports the same major+version when performing an update in order to maintain security and functionality.++If the change adds a new feature that is backwards compatible, for example in+TAP 4 and TAP 10, it should be part of a new minor version. These TAPs add+additional features to TUF, but clients that do not have these features will+still be able to securely and reliably perform updates from repositories that+support the TAPs. There may be minor differences as to which updates a client+installs across minor versions. If a repository maintainer is worried about the+impact of a minor change on clients, it may choose to wait to implement the+change with a major specification version (for example, they could remain on+version 2.4.6 after the release of 2.5). Patches are used to fix typos and make+small changes to existing features. More details about what constitutes a major,+minor, or patch change can be found at https://semver.org/.++### Changes to TAPs+In order to manage changes to TUF, TAPs shall be tied to a version of the TUF+specification.++Once a TAP is accepted, a TUF Version field in the header should list the first+TUF version that will include the TAP. The Preamble Header description in TAP 1+has been updated to include the TUF Version field.+++## How a repository updates++Repositories will add metadata for new TUF specification versions in new+directories.++As described in the [Rationale](#rationale), repositories should support multiple+TUF specification versions. In order to do so, this TAP proposes a new directory+structure for repositories. When a repository manager chooses to upgrade to a+new major TUF specification version, they create a new directory on the repository named+for the major version (for example 2.0.0). This directory will contain all+metadata files for the new specification version, but target files will remain in the+parent directory to save space. In this case the metadata files (in directories according to their spec+version) can point to target files relative to the parent directory. After creating+the directory, the repository creates and signs root, snapshot, timestamp, and+top-level targets metadata using the new TUF specification version and places these+metadata files in the directory. The root file should be signed by both the new+root key and the current root key (the root key from the most recent metadata in+the previous major specification version). Clients will now be able to use the new+metadata files once their TUF specification versions are also updated. After an update to+version 2.0.0, the repository structure may look like:+++```+- Target files+- 1.0.0+  |- metadata files+- 2.0.0+  |- metadata files+```++Repository updates to a new minor or patch specification version shall be done+by uploading new metadata files in the new format to the proper directory. So if+a repository updates from 2.0.0 to 2.1.0, the 2.1.0 metadata would go in the+directory named 2.0.0. Minor and patch version changes are backwards compatible,+so clients using version 2.0.0 will still be able to parse metadata written+using version 2.1.0.++A repository may continue to support old major TUF specification versions by creating+metadata in both the old location and the new directory. A repository manager+may maintain as many versions as desired, though any version with security+concerns should be phased out as soon as possible. This can be done by stopping+the creation of new metadata files in the directory for the phased out version.+In order to allow clients to parse the root metadata chain, root metadata files+shall not be deleted even once a version is deprecated.++A repository may indicate the planned phase out of a major version using an

I've read and thought about this and I can see why we're having an extended discussion on this point. I think this is a hard decision.

If you believe the repository is the arbiter of truth and trust, then keeping it in the root role makes sense. This does effectively let the repository's root role deprecate large swaths of targets files though. This can be good or bad.

If you think that the developer keys (targets metadata files) are what should be trusted, then having a field in targets makes sense. (I would argue for version number instead of timestamp since there isn't a global clock / sync requirement for most of TUF except perhaps to print a warning about outdated timestamp metadata.) This allows parties that delegate make the choice about what versions of metadata are alright. I do feel like this option means that no one will ever use this and that old metadata will be kept around indefinitely, because I just can't see developers worrying about using this flag...

mnm678

comment created time in 2 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha d736257cb56fea78ef3787dc0339ff28f6c8abe0

Uptane press

view details

push time in 2 months

push eventtheupdateframework/tuf

Trishank Karthik Kuppusamy

commit sha a57df738de6982d069501ee8b4d3042a378bda29

Update README.md Update list of adoptions Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank Karthik Kuppusamy

commit sha 6a7c60485cef67d1776455d84ff30b7c98abf364

Delete ADOPTERS.md Use a single source of truth on the .io website Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank Karthik Kuppusamy

commit sha 0f0bce5f21cbb56ad91c0a46ff97f56758dc6929

Update README.md Point to .io website for adoptions instead of duplicating information Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Justin Cappos

commit sha bba23757fd5853a550e1108d9936fbc07ce6ca20

Merge pull request #1086 from theupdateframework/trishankkarthik-patch-1 Remove specific adoptions from README

view details

push time in 2 months

PR merged theupdateframework/tuf

Reviewers
Remove specific adoptions from README

Fixes issue #:

As per https://github.com/theupdateframework/theupdateframework.io/pull/10

Description of the changes being introduced by the pull request:

Update list of adoptions

Please verify and check that the pull request fulfills the following requirements:

  • [ ] The code follows the Code Style Guidelines
  • [ ] Tests have been added for the bug fix or new feature
  • [ ] Docs have been added for the bug fix or new feature
+4 -25

5 comments

2 changed files

trishankkarthik

pr closed time in 2 months

pull request commenttheupdateframework/tuf

Remove specific adoptions from README

It seems a bit extreme to delete the adopters list from both the README and the ADOPTERS.md from the site. I'd prefer we update the content to make it more accurate instead...

The problem is in maintaining more than one source of truth for adoptions: one on theupdateframework.io and here. Seems best to maintain one well-curated one...

Got it. Makes sense to me.

trishankkarthik

comment created time in 2 months

pull request commenttheupdateframework/tuf

Remove adoptions from README

It seems a bit extreme to delete the adopters list from both the README and the ADOPTERS.md from the site. I'd prefer we update the content to make it more accurate instead...

On Tue, Jul 21, 2020 at 12:15 PM Trishank Karthik Kuppusamy < notifications@github.com> wrote:

@trishankatdatadog https://github.com/trishankatdatadog requested your review on: #1086 https://github.com/theupdateframework/tuf/pull/1086 Update README.md.

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/tuf/pull/1086#event-3572058085, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD5ETRX427M77N75LP3R4W5J3ANCNFSM4PAEONJQ .

trishankkarthik

comment created time in 2 months

pull request commenttheupdateframework/taps

Suggested changes to TAP 11 and POUF 1

Great! Will merge!

joshuagl

comment created time in 2 months

push eventtheupdateframework/taps

Joshua Lock

commit sha a6d6b59bdc64e7e1ca1cec181fb49641d1f1e352

Tweak TAP 11 * Add the TAP number to the header * Fix the links to sections

view details

Joshua Lock

commit sha 88f99a873d7e2dfdf6058730a8a721ac40baf7f0

TAP 11: recommend listing implementation version number

view details

Joshua Lock

commit sha 511deea9d24b6ccef890e6f573137b020f76b2d6

TAP 11: suggest POUF's list version history It will be useful to readers to be able to easily see a summarised history of changes in the POUF and the version numbers of the implementation they affect.

view details

Joshua Lock

commit sha e1173223bac25fee47a8a762e5c71efa85bf933c

TAP 11: Update last modified Update the last modified header to today's date.

view details

Joshua Lock

commit sha 42c5f5518f7733613c58552655855b0869a8c240

Update POUF 1 Update POUF 1 to match the latest (0.12.2) version of the reference implementation.

view details

Joshua Lock

commit sha 0bcd9ff784f2888fb44b61db4be0be954f2792e3

Update POUFs/reference-POUF/pouf1.md Update the semantic versioning mention to link to the semver spec Co-authored-by: Marina Moore <mnm678@users.noreply.github.com>

view details

Joshua Lock

commit sha 642289b3a7d80ad3fe2cbc2fe2915d18eb35848e

Update tap11.md Make it clear that "TUF Version(s) Implemented" is referring to the specification versions supported by the POUF. Co-authored-by: Marina Moore <mnm678@users.noreply.github.com>

view details

Joshua Lock

commit sha 656a051a3e31b81ac992d7b9b1b597323a8c2698

Mark TAP 11 as Accepted Per the TAP editors meeting on Friday 17-Jul-2020 TAP 11 has been accepted: https://hackmd.io/MlPcGPs-RamfAA6C-Zq1Jw?view#Minutes Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Justin Cappos

commit sha 7331a806fa3f8c6ca1bf451037167a6dee5f486a

Merge pull request #113 from joshuagl/joshuagl/POUF1 Suggested changes to TAP 11 and POUF 1

view details

push time in 2 months

PR merged theupdateframework/taps

Suggested changes to TAP 11 and POUF 1

I was reading about POUF's in TAP 11, which made me want to update POUF 1 to match the current state of the reference implementation. Which further made me want to suggest some changes to TAP 11 to track what I think are useful pieces of information in the POUF.

Changes in the PR include:

  • recommend the POUF list version numbers of the implementation which are covered by the POUF
  • suggest POUF's include a list of changes across versions
  • Update POUF 1 to match the reference implementation, including the TAP 11 suggestions above
+60 -25

9 comments

3 changed files

joshuagl

pr closed time in 2 months

push eventtheupdateframework/taps

Joshua Lock

commit sha e265edf4a19b00e0206985f348ef7b6a5453b858

TAP 5: mark as rejected TAP 5 was designed to fulfil two primary use-cases: 1. restricting trust in a community repository to a single project 2. trusting a mirror only for snapshot and targets metadata TAP 5 addresses both of these use-cases on the repository, effectively by setting up an intermediary repository to filter/restrict the upstream repository configuration. This design is problematic for the second use-case, as this means that a party with a threshold of root keys can no longer affect changes on the Timestamp and Snapshot roles. TUF is designed with the Root role as the locus of trust, removing that control is antithetical to the design of the system. The first use-case, restricting trust to a single project, is unwieldy as it requires setting up an in-house repository in order to filter the views on the upstream repository. This use-case is better suited by the proposal "User Selection of the Top-Level Target Files Through Mapping Metadata" (https://github.com/theupdateframework/taps/pull/118), which extends the map file in TAP 4 to put control for selecting trusted targets in the hands of users who can configuring the client (such as the end user, a system adminstrator or client developer). Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Justin Cappos

commit sha 3130ba1b603f0e16a789878d8519d379464f816d

Merge pull request #123 from joshuagl/joshuagl/tap5 TAP 5: mark as rejected

view details

push time in 2 months

PR merged theupdateframework/taps

TAP 5: mark as rejected

I've tried to capture the outcome of discussion related to TAP 5 from the TAP Editors meeting on Friday in the commit message here.

  • Have I correctly captured the issues we discussed?
  • Is there a better place to document the reason for rejection than the commit message adding the "Rejected" status?

CC: meeting attendees @mnm678 @trishankatdatadog @JustinCappos @lukpueh

+3 -3

2 comments

2 changed files

joshuagl

pr closed time in 2 months

pull request commenttheupdateframework/taps

TAP 5: mark as rejected

Looks great! Would you kindly also include the README change in this?

(If anyone objects, please say so now before I merge...)

joshuagl

comment created time in 2 months

pull request commenttheupdateframework/taps

Suggested changes to TAP 11 and POUF 1

I've pushed an extra patch to mark TAP 11 as Accepted, as discussed in the editors meeting on Friday

I think we also need the README.md updated as part of this change. Once that's done unless someone else objects, I will merge the PR...

joshuagl

comment created time in 2 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 64d309feab7af5a108f907b234fdc518ee21ee83

Add TUF news

view details

push time in 2 months

pull request commenttheupdateframework/theupdateframework.io

Update adoptions.yaml

If we're removing VMware, shouldn't the main page be fixed too? https://deploy-preview-10--theupdateframework.netlify.app/

trishankatdatadog

comment created time in 2 months

pull request commenttheupdateframework/theupdateframework.io

Update adoptions.yaml

It makes sense to me. I don't want to be accused of overclaiming, especially by someone in that community.

On Fri, Jul 17, 2020 at 1:17 PM Trishank Karthik Kuppusamy < notifications@github.com> wrote:

I'm not sure what to do with "inspired"... Maybe a separate section, but it feels like we would need them to do a post or some other public mention for us to point to.

Should we just remove them for now, then?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/theupdateframework.io/pull/10#issuecomment-660235038, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD3K4WEIMTRRJXUZIK3R4CBSXANCNFSM4O2CAW2A .

trishankatdatadog

comment created time in 2 months

pull request commenttheupdateframework/theupdateframework.io

Update adoptions.yaml

Let's just remove abandoned things, I think.

I'm not sure what to do with "inspired"... Maybe a separate section, but it feels like we would need them to do a post or some other public mention for us to point to.

On Fri, Jul 17, 2020 at 11:51 AM Trishank Karthik Kuppusamy < notifications@github.com> wrote:

+1 from me. Maybe with smaller logos, or no logo, to de-emphasise them?

Right, and we can even mark some integrations as abandoned (like Rubygems), if so desired.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/theupdateframework.io/pull/10#issuecomment-660183201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD3X3MIQWD4TPCZ3ONLR4BXPDANCNFSM4O2CAW2A .

trishankatdatadog

comment created time in 2 months

pull request commenttheupdateframework/theupdateframework.io

Update adoptions.yaml

Okay, what about DigitalOcean?

trishankatdatadog

comment created time in 2 months

issue commentuptane/uptane-standard

Should a metadata file still be valid if it meets the threshold of valid signatures, but also includes one or more invalid signatures?

I think that both of these MUST be considered valid. (If you feel the spec is ambiguous, we likely should clarify it.)

The first case can happen when you include x in a newer version of root metadata (for example the next iteration), so this has to be handled correctly or adding / rotating keys is a pain.

Something like the second case could happen when you are changing / adding signing algorithms. If B is using some sort of signing scheme the client doesn't notice (but will know how to parse after the update), this case can occur.

tkfu

comment created time in 2 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 45ee44c1e98d1568d7d50606217cfcaa9ad0dc96

TikTok quote fix

view details

push time in 3 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha ef78b5f274caa1e2c00fe8b4a516815255472908

TikTok

view details

push time in 3 months

issue commenttheupdateframework/taps

TAP process (TAP 1)

I think we should fix these.

Justin

On Fri, Jul 10, 2020 at 10:29 AM Joshua Lock notifications@github.com wrote:

Another question to consider, do we expect links to the augmented reference implementation to remain valid? i.e. tap4 links to https://github.com/theupdateframework/taps/blob/master/tap4.md#augmented-reference-implementation a branch on GitHub which no longer exists, so anyone following the link gets a 404.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/taps/issues/121#issuecomment-656706027, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD7CATCOOBFME4MBFUTR24QV7ANCNFSM4OUOZZRA .

joshuagl

comment created time in 3 months

pull request commenttheupdateframework/taps

Added TAP for TUF Version Management

Apologies for the noise, I hope you all don't mind me doing so much of my thinking "out loud" here.

No, this is really great! We want to have this sort of rationale / thinking captured somewhere. I'm sure that others may have had similar thoughts and the fact that your thought process is written down clearly may help others come to the same conclusion.

mnm678

comment created time in 3 months

issue commentcncf/sig-security

[Assessment] Cloud Native Buildpacks

Okay, great. We need a lead from their side to step forward.

We will also need other reviewers as well to get this going.

sclevine

comment created time in 3 months

pull request commenttheupdateframework/taps

Added TAP for TUF Version Management

Interesting perspective. I'd like for those who are interested to have a chat and see if we can understand your perspective better and perhaps reconcile the differences. Our thought when working on this TAP was we were strictly making it better for implementers and maintainers, but if there is some potential we could be doing the opposite, we should better understand how...

On Thu, Jul 9, 2020 at 11:07 AM Joshua Lock notifications@github.com wrote:

@joshuagl commented on this pull request.

Some observations;

I have mixed feelings about this TAP. On one hand, it seems like a well thought out and logical approach to the problem – kudos for that Marina. On the other, do we really want/need this to be part of the specification? As the specification moves away from recommending wire formats and even repository representations, should it seek to encode concepts of version management? Of course, with my reference implementation maintainer hat on – this would be a complexity and maintenance burden increase in the implementation.

Perhaps a route forward would be to make an advisory TAP for version management and ensure there's sufficient metadata in the specification, and sufficient discipline around version management in the specification, to support it?

In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452199527 :

+## Use case 5: Backwards compatibility for existing clients

+Existing TUF clients (written before this TAP is implemented) will still expect

+to download and parse metadata. Before this TAP there was no method for determining compatibility

+between a client and a repository, so existing TUF repositories should continue

+to distribute metadata using their existing method to support existing clients. This

+means that this mechanism for allowing backwards compatible updates must itself

+be backwards compatible.

+# Rationale

+We propose this TAP because as TUF continues to evolve, the need for TUF clients

+and repositories to upgrade their TUF metadata format will grow. This sets up the potential for clients

+that are no longer able to perform updates because they cannot parse the

+metadata generated by repositories, or for clients to install the wrong images

⬇️ Suggested change

-metadata generated by repositories, or for clients to install the wrong images

+metadata generated by repositories, or for clients to install the wrong targets


In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452199798 :

+Existing TUF clients (written before this TAP is implemented) will still expect

+to download and parse metadata. Before this TAP there was no method for determining compatibility

+between a client and a repository, so existing TUF repositories should continue

+to distribute metadata using their existing method to support existing clients. This

+means that this mechanism for allowing backwards compatible updates must itself

+be backwards compatible.

+# Rationale

+We propose this TAP because as TUF continues to evolve, the need for TUF clients

+and repositories to upgrade their TUF metadata format will grow. This sets up the potential for clients

+that are no longer able to perform updates because they cannot parse the

+metadata generated by repositories, or for clients to install the wrong images

+due to changes in TUF. Both of these issues prevent clients from installing the

+images intended by repository managers, and could lead to critical security or

⬇️ Suggested change

-images intended by repository managers, and could lead to critical security or

+targets intended by repository managers, and could lead to critical security or


In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452200656 :

+whether the TUF specification version they implement is compatible with the TUF

+version of the metadata they receive. This ensures that clients parse

+metadata according to the correct version to prevent errors from any changes to

+the metadata in the new version. Second, clients need a way to use this

+information to determine how to access metadata that is compatible with the

+version of the TUF specification they implement.

+To address the first issue, this TAP proposes standardizing the specification

+version field to separate breaking changes from non-breaking changes and

+ensure that the field can be compared across clients and repositories.

+Separating out non-breaking changes allows these backwards compatible changes to

+happen at any time without affecting TUF's operation. Therefore, clients and

+repositories can still coordinate after a non-breaking change occurs. One common

+framework used to separate versions by type is Semantic Versioning. Semantic

+Versioning is a versioning scheme popular across open source projects that

+categorizes specification versions by the scope and criticality of their

⬇️ Suggested change

-categorizes specification versions by the scope and criticality of their

+categorizes specification by the scope and criticality of their


In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452200808 :

+version of the metadata they receive. This ensures that clients parse

+metadata according to the correct version to prevent errors from any changes to

+the metadata in the new version. Second, clients need a way to use this

+information to determine how to access metadata that is compatible with the

+version of the TUF specification they implement.

+To address the first issue, this TAP proposes standardizing the specification

+version field to separate breaking changes from non-breaking changes and

+ensure that the field can be compared across clients and repositories.

+Separating out non-breaking changes allows these backwards compatible changes to

+happen at any time without affecting TUF's operation. Therefore, clients and

+repositories can still coordinate after a non-breaking change occurs. One common

+framework used to separate versions by type is Semantic Versioning. Semantic

+Versioning is a versioning scheme popular across open source projects that

+categorizes specification versions by the scope and criticality of their

+changes. Breaking changes in a specification would warrant a MAJOR version

⬇️ Suggested change

-changes. Breaking changes in a specification would warrant a MAJOR version

+changes. Breaking changes in the specification would warrant a MAJOR version


In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452205526 :

+# Specification

+As stated above, this TAP defines a variety of procedures to be added to the

+update process on both clients and repos. These changes include the way in which

+version numbers are determined, the addition of new directories on repositories,

+new metadata parsing functions on clients, and a new process for finding

+compatible metadata.

+For clarity, throughout this TAP upgrading refers to the process of moving

+from one TUF specification version to another while updating refers to the

+process of downloading and validating packages as specified by TUF. The rest of

+this section details the changes to the TUF specification recommended by this

+TAP.

+## Version Number Format

This recommendation of the TAP has already been implemented and documented for the specification https://github.com/theupdateframework/specification#versioning

In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452205878 :

+still be able to securely and reliably perform updates from repositories that

+support the TAPs. There may be minor differences as to which updates a client

+installs across minor versions. If a repository maintainer is worried about the

+impact of a minor change on clients, it may choose to wait to implement the

+change with a major specification version (for example, they could remain on

+version 2.4.6 after the release of 2.5). Patches are used to fix typos and make

+small changes to existing features. More details about what constitutes a major,

+minor, or patch change can be found at https://semver.org/.

+### Changes to TAPs

+In order to manage changes to TUF, TAPs shall be tied to a version of the TUF

+specification.

+Once a TAP is accepted, a TUF Version field in the header should list the first

+TUF version that will include the TAP. The Preamble Header description in TAP 1

+shall be updated to include the TUF Version field.

⬇️ Suggested change

-shall be updated to include the TUF Version field.

+has been updated to include the TUF Version field.


In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452208511 :

+For existing TUF clients to continue operation after this TAP is implemented,

+repositories may store metadata from before TUF 1.0.0 in the top level

+repository (with no directory named 0.0.0). This allows existing clients to

+continue downloading metadata from the repository. So a TUF repository that

+upgrades from version 0.12.0 to version 1.0.0 may look like:

Agreed. Though the text (and the example below) needs updating as the specification is already at 1.0.x

In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452232699 :

+The specification that follows adopts the third option, and supports version

+changes on both clients and repositories. This requires both clients and

+repositories to maintain multiple versions of the TUF spec, as well as changes

+to the way repositories store metadata and clients parse this metadata.

+For the repositories this means continuing support for old TUF versions for some

+period of time after upgrading. This grace period gives the client time to

+upgrade to a new specification version. Versions with breaking changes are kept

+in separate directories that allow a client to choose the most recent metadata

+they support. To save space, target files should remain in the parent directory

+on the repository. The metadata files (in directories according to their spec

  • version) can point to target files relative to the parent directory.

+On the client side, this TAP also requires maintenance of multiple specification

+versions to allow for communication with various repositories. To do so, it is

That's how I'm reading it.

In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452233242 :

+For repositories, this means continuing support for old TUF versions for some

+period of time after upgrading. This grace period gives existing clients that

+implement old versions of the TUF specification time to implement support for a

+new specification version. Repositories achieve this using a directory structure

+with a directory for each supported TUF specification version. These directories

+contain metadata that supports the given TUF specification version. Using these

+directories, a client is able to choose the most recent metadata they support.

+More details about this directory structure are contained in the specification.

+On the client side, this TAP also requires maintenance of multiple versions that

+support different TUF specification

+versions to allow for communication with various repositories. To do so, it is

+recommended that clients maintain functions that can be used to validate

+metadata from previous TUF specification versions. These functions allow a

+client to maintain old versions of the specification while still supporting the

+most recent version.

As I'm reading it, only delegated targets files can be a different version. All top-level metadata must be the same specification version.

In candidate-tuf-versions.md https://github.com/theupdateframework/taps/pull/107#discussion_r452279386 :

+period of time after upgrading. This grace period gives existing clients that

+implement old versions of the TUF specification time to implement support for a

+new specification version. Repositories achieve this using a directory structure

I wonder whether this TAP should recommend a mechanism for identifying when a repositories metadata is no longer supported or on its way to being deprecated.

If I have a client which only supports specification version 1.0.0, but the repository intends to stop updating 1.0.0 metadata, it might be useful to be able to detect that.

Should repository metadata be able to signal its deprecation timeframe?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/taps/pull/107#pullrequestreview-445591792, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODYZLRA3AHGMOFAWDLDR2XMLXANCNFSM4GLTCGFA .

mnm678

comment created time in 3 months

push eventtheupdateframework/taps

Joshua Lock

commit sha 316ad2eaa9b2f0c98ddf15d46432007aa830e3d7

Update TAP 9 to final This TAP is already reflected in the specification and the reference implementation. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Joshua Lock

commit sha cbedf59aca0b40cb4bbd19123f4982e0cd232745

Update TAP 6 to Final This TAP is already reflected in the specification and the reference implementation. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Joshua Lock

commit sha fab3a4f0d93ddb5e4b65882be3aed094bc232d64

Update TAP 10 to Final This TAP is already reflected in the specification and the reference implementation. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Justin Cappos

commit sha af8bce0b374625362395c78b5e04d7b595458efc

Merge pull request #122 from joshuagl/joshuagl/final-taps Mark TAPs 6, 9 and 10 as final

view details

push time in 3 months

PR merged theupdateframework/taps

Mark TAPs 6, 9 and 10 as final

Each is included in the specification and the reference implementation.

+3 -3

0 comment

3 changed files

joshuagl

pr closed time in 3 months

pull request commentuptane/POUFs

[WIP] Add POUF template

Is there a standard way to indicate that a POUF does not implement Uptane yet? Would that mean leaving Uptane Version Implemented: blank, or using a particular string to indicate non-compliance?

We don't have an official way to support this, but leaving the Uptane Version Implemented blank would be a good way to indicate that the POUF hasn't yet implemented all the features in Uptane. It might also be good to include a note in the abstract.

I agree that some note (as obvious as possible) is a great idea.

But we also really don't do much but just assign the POUF number, right? We could hold off from actually assigning the number until a POUF is compliant.

mnm678

comment created time in 3 months

Pull request review commentuptane/POUFs

[WIP] Add POUF template

+* POUF:+* Title:+* Version:+* Last-Modified:+* Author:+* Status:+* Uptane Version Implemented:+* Created:++# Abstract++# Protocols++This section describes the protocols used to transmit data in the implementation. At a minimuc, this should answer the following questions:++What encoding format is used? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#meta_structures)++Are any files hosted? What protocol is used to transmit hosted files?++## Message Handler Table++What messages are sent by Uptane entities?+++| Request | Sender | Receiver | Data | Response | Specification Reference |+| ------- | ------ | -------- | ---- | -------- | ----------------------- |+++# Operations+This section includes descriptions of optional features from the standard, as+well as any additional features supported by the implementation. At a minimum,+this should include the following:++Which ECU is used as the primary ECU?+* The primary ECU MAY be the same ECU that communicates with the server (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#rfc.section.5).++What delegation features are supported (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#targets_role_delegations)?+* How does the implementation get a secure source of time?+* Are custom delegated targets roles supported?+* Are terminating delegations supported?+* Are multi-role delegations (TAP 3) supported?++What value is used for the public key identifier? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#common_metadata)++Does the root file support mapping roles to urls (TAP 5)? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#root_meta)++Is there any additional or custom metadata included in targets metadata? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#targets_meta, https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#custom-metadata-about-images)++How are the filenames for delegations listed? Are wildcards supported? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#delegations_meta)++Does snapshot include the root filename and version number? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#snapshot_meta)++How many repositories does the implementation use? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#repo_mapping_meta)++How does the implementation specify repository mapping metadata? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#repo_mapping_meta)++How do ECUs securely access the current time? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#server-repository-implementation-requirements)++Is the image repository interface public? Does it require authentication? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#image-repository)++Is the director repository interface public? Does it support encryption? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#director_repository)++How does the director repository identify a vehicle? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#directing-installation-of-images-on-vehicles)++Does the director repository make any additional checks? What does it do it a check fails? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#directing-installation-of-images-on-vehicles)++What additional data about ECUs and vehicles is stored in the inventory database? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#inventory_db_)++Is the ECU key symmetric? Is the same key used for encryption and signing? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#build-time-prerequisite-requirements-for-ecus)++Does the implementation support sending diffs of the vehicle version manifest? If so, how can the director request the full manifest? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#construct_manifest_primary)++Do any secondaries not have storage? If so, how will they request images from the primary and should they backup their previous working image? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#send_images_primary)++What are the preconditions for installing an image? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#install_image)++Does the primary write version reports to disk? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#create_version_report)++Do full verification secondaries check that all metadata from the director and image repositories match? (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#full_verification)

A primary should always do full verification, right?

mnm678

comment created time in 3 months

push eventsecure-systems-lab/ssl-site

Lois Anne DeLong

commit sha e61b505bc65ed728931f9c266ee8a9d6068a196d

Adding some links--Don't merge till I'm done

view details

Lois Anne DeLong

commit sha e72c15271471f8049fbfa35e5fb328f1eb1d7485

fixing more links

view details

Lois Anne DeLong

commit sha c3a71fc01b87bc0b1165c1b5d9a0531ee578ab3f

Added photos

view details

Lois Anne DeLong

commit sha 64cedaacf79d93af2316c4d4bebfe7eb87e18d50

Update 2020-07-03-grad-phds.md fixed name of Dan photo

view details

Justin Cappos

commit sha c6dabaf7cd1af7bc0a460e14d24b669685248454

Merge pull request #111 from secure-systems-lab/jhdalek55-patch-1 Adding some links--Don't merge till I'm done

view details

push time in 3 months

PR merged secure-systems-lab/ssl-site

Adding some links--Don't merge till I'm done

I'm adding links and photos, so this will probably require several commits. I want to make sure there are no problems before finishing these edits.

+11 -7

1 comment

1 changed file

jhdalek55

pr closed time in 3 months

issue commentsecure-systems-lab/securesystemslib

key format inconsistency

@mnm678 This is obviously one for you to watch / participate in as well...

shibumi

comment created time in 3 months

Pull request review commenttheupdateframework/taps

Add candidate TAP for succinct hash bin delegations

+* TAP:+* Title: Succinct hash bin delegations+* Version: 1+* Last-Modified: 02-07-2020+* Author: Marina Moore, Justin Cappos+* Status: Draft+* Created: 23-06-2020+* TUF-Version:+* Post-History:++# Abstract++TUF delegating metadata contains the keyid and path for each delegation, so when a single metadata file delegates to many others the delegating metadata’s size increases proportional to the number of delegations. Clients must download this large delegating metadata file when they update any image it delegates to, therefore large delegating metadata increases the client’s metadata overhead. To reduce the metadata overhead for targets metadata that contains many delegations, TUF supports hashed bin delegations. Hashed bin delegations use targets files that delegate to ‘bin’ roles that delegate to the actual targets. Targets are distributed to bins using the hash of the target filename. Using hashed bin delegations, the delegating metadata only delegates to the bins, and so contain less data. Thus, hashed bin delegations reduce the client’s metadata overhead.++Currently, hashed bin delegations function much like standard TUF delegations, so the delegating metadata lists the keyid and path for each bin. In practice, most hashed bin delegations use the same keyid for each bin and these bins are hashed in a predictable pattern, stored in files with predictable names, and stored in a common location. Furthermore the delegating metadata contains duplicate keyid and path information for each bin. This duplicate information adds to the metadata overhead without providing useful information to the client.++This TAP proposes adding a field to delegating metadata to describe hashed bin delegations that allows a delegating party to succinctly describe the bins it will delegate to when the hash bin delegation follows a common pattern.++# Motivation++This TAP supports the following use case:++Suppose a single targets file contains a very large number of delegations or targets. The owner of this targets file wishes to reduce the metadata overhead for clients, and so uses hashed bin delegations. They will use the same key to sign each bin delegation. They would like to list this key a single time in the delegation to prevent repetition and a large targets metadata filesize. Currently, the delegating metadata will list the keyid for this key in every bin delegation, potentially repeating the same 32-bit value thousands of times. The first four delegations in the resulting metadata would include:+```+“delegations”:{ "keys" : {+       abc123 : abcdef123456,+       },+   "roles" : [{+       "name": alice.hbd-00,+       "keyids" : [ abc123 ] ,+       "threshold" : 1,+       "path_hash_prefixes" : [ 00* ],+        "paths" : [ “path/to/directory/” ],+       "terminating": false,+   },+{+       "name": alice.hbd-01,+       "keyids" : [ abc123 ] ,+       "threshold" : 1,+       "path_hash_prefixes" : [ 01*],+        "paths" : [ “path/to/directory/” ],+       "terminating": false,+   },+{+       "name": alice.hbd-02,+       "keyids" : [ abc123 ] ,+       "threshold" : 1,+       "path_hash_prefixes" : [ 02* ],+        "paths" : [ “path/to/directory/” ],+       "terminating": false,+   },+{+       "name": alice.hbd-03,+       "keyids" : [ abc123 ] ,+       "threshold" : 1,+       "path_hash_prefixes" : [ 03*],+        "paths" : [ “path/to/directory/” ],+       "terminating": false,+   },... ]+ }+ ```+Every client will then have to download this large delegating metadata file. Note that all of the information in italics above is exactly the same in each delegation. The only data that differs between these delegations are the bolded fields, the name and path_hash_prefix. The name has a common prefix (underlined), so only differs by a count and the path_hash_prefix is generated using the hash algorithm and number of bins.++# Rationale++Hashed bin delegations commonly use the same key for each bin in order to allow for automated signing of targets files. If the same key is used for all bins, this key should only need to be listed once in the delegating metadata.++Similarly, bins are usually named using a numbering system with a common prefix (i.e. alice.hbd-0, alice.hbd-1, …). The delegating metadata only needs to describe this naming scheme and the location that these metadata files are stored.++The delegating metadata could significantly reduce the client’s metadata overhead by providing a succinct description of the keyid and prefix instead of repeating these for each delegation.++# Specification++This TAP adds the following extension to delegations:+```+(“succinct_hash_delegations” : {+    “prefix_bit_length” : BIT_LENGTH+})+```+Where 2^BIT_LENGTH is the number of bins. BIT_LENGTH must be an integer between 1 and 32 (inclusive).

Why 32? Why not 64? Also, I feel like if we need to accommodate 4,294,967,296 bins, something is wrong.

Right, this is exactly the reason. 264 is just absurdly large. We may use a setting like 220 or so for DockerHub, so thought 24 was a little too tight. We wanted to make it divisible by 8 so that it is the first so many bytes at most.

mnm678

comment created time in 3 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha 71fae8c1a6aabbdd28b099c333f426361acbaae2

removing space to test

view details

push time in 3 months

push eventsecure-systems-lab/ssl-site

Justin Cappos

commit sha d5bad53b5600ca64fc5a5ddce41fa35fdc56e660

space to test push fixes

view details

push time in 3 months

push eventsecure-systems-lab/ssl-site

Lois Anne DeLong

commit sha 3935a7edd1bdf3076cdb3bdc140a9db519582c45

Added Dan / Santiago blog posts Added blog post and two photos

view details

Lois Anne DeLong

commit sha 56642a26a0356d9db630e298285ab20183509b32

Create 2020-07-3-grad-phds.md added links

view details

Justin Cappos

commit sha d6d75fa983454cd16defc985fd73fdf1e4380ebf

Merge pull request #110 from secure-systems-lab/add-grad-blog Add grad blog

view details

push time in 3 months

PR merged secure-systems-lab/ssl-site

Add grad blog

Added blog about Dan and Santiago graduating Added two photographs Added links

+42 -0

0 comment

4 changed files

jhdalek55

pr closed time in 3 months

issue commentcncf/sig-security

[Assessment] Cloud Custodian

yes - still able to participate as reviewer (or lead if desired) - no change to the conflict statement (still no conflicts as above)

Okay, I'll list you as lead above (for at least the time being). I think you'd do well in the role.

kapilt

comment created time in 3 months

issue commentcncf/sig-security

[Assessment] Cloud Custodian

I would be happy to participate as an additional reviewer.

My conflict statement (no conflicts) is the same as above.

kapilt

comment created time in 3 months

issue commentcncf/sig-security

[Assessment] Cloud Custodian

We will need to get participants set up again. I'm going to remove everyone from the list, but I do hope that many of: @rficcaglia , @JustinCappos , @ashutosh-narkar , @steven-hadfield , @ericavonb, @ultrasaurus, @cseader can participate again.

Please weigh in here if you can work on this assessment.

kapilt

comment created time in 3 months

issue commentcncf/sig-security

[Assessment] Cloud Custodian

We should have this done well ahead of their incubation assessment. We may need to shift our review team, but I think we can do this to cover this project.

I'd encourage @kapilt and others to let us know as soon as they are ready to work on this. Right now, we have capacity to get this moving forward.

kapilt

comment created time in 3 months

Pull request review commenttheupdateframework/taps

TAP13 draft

+* 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](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 +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 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
what would have been the top-level targets role.  TAP 8 also provides support for cases where the key need to be rotated
JustinCappos

comment created time in 3 months

push eventtheupdateframework/taps

Justin Cappos

commit sha 64302b05945d28b6ba717176b79185c7131d36a0

Update tap13.md Co-authored-by: lukpueh <lukas.puehringer@nyu.edu>

view details

push time in 3 months

push eventtheupdateframework/taps

Justin Cappos

commit sha 0de3dc8f5420184f726cbb4e33f1ef8d3f684de1

Update tap13.md Co-authored-by: lukpueh <lukas.puehringer@nyu.edu>

view details

push time in 3 months

issue commentsecure-systems-lab/code-style-guidelines

Consider not curating a full custom Python code-style guide

I'm also supportive of this.

We should take a quick look / poll of other Python projects in the lab to be sure this won't cause a major issue first...

lukpueh

comment created time in 3 months

more